One document matched: draft-ietf-simple-msrp-cema-05.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200811" category="std" docName="draft-ietf-simple-msrp-cema-05.txt" obsoletes="" extends="4975" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="MRSP-CEMA">
Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
</title>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<author initials="S.B." surname="Blau" fullname="Staffan Blau">
<organization>Ericsson</organization>
<address>
<postal>
<code>12637</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>staffan.blau@ericsson.com</email>
</address>
</author>
<author fullname="Eric Burger" initials="E.W." surname="Burger">
<organization>Georgetown University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>37th and O Streets, NW</street>
<city>Washington</city>
<region>DC</region>
<code>20057-1232</code>
<country>United States of America</country>
</postal>
<phone></phone>
<facsimile>+1 530 267 7447</facsimile>
<email>eburger@standardstrack.com</email>
<uri>http://www.standardstrack.com</uri>
</address>
</author>
<date year="2012" />
<area>Transport</area>
<workgroup>SIMPLE Working Group</workgroup>
<keyword>MSRP</keyword>
<keyword>CEMA</keyword>
<keyword>Middlebox</keyword>
<keyword>IBCF</keyword>
<keyword>SBC</keyword>
<keyword>relay</keyword>
<abstract>
<t>
This document defines a Message Session Relay Protocol (MSRP)
extension, Connection Establishment for Media Anchoring (CEMA).
Support of the extension is optional. The extension allows
middleboxes to anchor the MSRP connection, without the need for
middleboxes to modify the MSRP messages, and thus also enables a
secure end-to-end MSRP communication in networks where such middleboxes
are deployed. The document also defines a Session Description Protocol
(SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate
support of the CEMA extension.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>
The Message Session Relay Protocol (MSRP) <xref format="default"
pageno="false" target="RFC4975" /> expects to use MSRP relays
<xref format="default" pageno="false" target="RFC4976" /> as a means for
Network Address Translation (NAT) traversal and policy enforcement.
However, many Session Initiation Protocol (SIP) <xref format="default"
pageno="false" target="RFC3261" /> networks, which deploy MSRP, contain
middleboxes. These middleboxes anchor and control media, perform tasks
such as NAT traversal, performance monitoring, address
domain bridging, interconnect Service Layer Agreement (SLA) policy
enforcement, and so on. One example is the Interconnection Border Control
Function (IBCF) <xref format="default" pageno="false" target="GPP23228" />,
defined by the 3rd Generation Partnership Project (3GPP). The IBCF controls a
media relay that handles all types of SIP session media such as voice, video,
MSRP, etc.
</t>
<t>
MSRP, as defined in RFC 4975 <xref format="default" pageno="false"
target="RFC4975" /> and RFC 4976 <xref format="default" pageno="false"
target="RFC4976" />, cannot anchor through middleboxes. The reason is that
MSRP messages have routing information embedded in the message. Without an
extension such as CEMA, middleboxes must read the message to change the routing
information. This occurs because middleboxes modify the address:port information
in the Session Description Protocol (SDP) <xref format="default" pageno="false"
target="RFC4566" /> c/m-line in order to anchor media. An "active" <xref
format="default" pageno="false" target="RFC6135" /> MSRP UA establishes
the MSRP TCP or TLS connection based on the MSRP URI of the SDP 'path' attribute.
This means that the MSRP connection will not be routed through the middlebox,
unless the middlebox also modifies the MSRP URI of the topmost SDP 'path' attribute.
In many scenarios this will prevent the MSRP connection from being established.
In addition, if the middlebox modifies the MSRP URI of the SDP 'path'
attribute, then the MSRP URI comparison procedure <xref format="default"
pageno="false" target="RFC4975" />, which requires consistency between the address
information in the MSRP messages and the address information carried in the MSRP URI
of the SDP 'path' attribute, will fail.
</t>
<t>
The only way to achieve interoperability in this situation is for the middlebox
to act as an MSRP back-to-back User Agent (B2BUA). Here the MSRP B2BUA acts as the
endpoint for the MSRP signaling and media, performs the corresponding modification
in the associated MSRP messages, and originates a new MSRP session towards the actual remote
endpoint. However, the enabling of MSRP B2BUA functionality requires substantially more
resource usage in the middlebox, that normally result in negative performance impact.
In addition, the MSRP message needs to be exposed in clear text to the MSRP B2BUA, which
violates the end-to-end principle <xref format="default" pageno="false" target="RFC3724"/> .
</t>
<t>
This specification defines an MSRP extension, Connection Establishment for Media
Anchoring (CEMA). CEMA in most cases allows MSRP endpoints to communicate through
middleboxes, as defined in <xref format="default" pageno="false" target="S.conventions"/>,
without a need for the middleboxes to be an MSRP B2BUA. In such cases, middleboxes, that
want to anchor the MSRP connection simply modify the SDP c/m-line address information, similar
to what the middleboxes do for non-MSRP media types. MSRP endpoints that support the CEMA
extension will use the SDP c/m-line address information for establishing the TCP or TLS
connection for sending and receiving MSRP messages.
</t>
<t>
The CEMA extension is backward compatible, meaning that CEMA-enabled MSRP endpoints
can communicate with non-CEMA-enabled endpoints. In scenarios where
MSRP endpoints do not support the CEMA extension, an MSRP endpoint
that supports the CEMA extension behaves in the same way as an MSRP
endpoint that does not support it. The CEMA extension only provides
an alternative mechanism for negotiating and providing address
information for the MSRP TCP connection. After the creation of the
MSRP connection, an MSRP endpoint that supports the CEMA extension
acts according to the procedures for creating MSRP messages, performing
checks when receiving MSRP messages defined in RFC 4975 and, when it
is using a relay for MSRP communications, RFC 4976.
</t>
</section>
<section anchor="S.conventions" title="Conventions" toc="default">
<t>
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 <xref
format="default" pageno="false" target="RFC2119" />.
</t>
<t>
Definitions:
</t>
<t>
Fingerprint Based TLS Authentication: An MSRP endpoint that uses a
self-signed certificate and sends a fingerprint (i.e., a hash of the
self-signed certificate)in SDP to the other MSRP endpoint. This
fingerprint binds the TLS key exchange to the signaling plane and
authenticates the other endpoint based on trust in the signaling plane.
</t>
<t>
Name Based TLS Authentication: An MSRP endpoint that uses a
certificate from a trusted certification authority and the other
endpoint matches the hostname in the received TLS communication
SubjectAltName extension towards the hostname received in the MSRP
URI in SDP.
</t>
<t>
B2BUA: This is an abbreviation for back-to-back user agent.
</t>
<t>
MSRP B2BUA: A network element that terminates an MSRP connection from one
MSRP endpoint and reoriginates that connection towards another MSRP
endpoint. Note the MSRP B2BUA is distinct from a SIP B2BUA. A SIP B2BUA
terminates a SIP session and reoriginates that session towards another SIP
endpoint. In the context of MSRP, a SIP endpoint initiates a SIP session
towards another SIP endpoint. However, that INVITE may go through, for
example, an outbound Proxy or inbound Proxy to route to the remote SIP
endpoint. As part of that SIP session an MSRP session, that may follow
the SIP session path, is negotiated. However, there is no requirement
to co-locate the SIP network elements with the MSRP network elements.
</t>
<t>
TLS B2BUA: A network element that terminates security associations (SAs)
from endpoints, and establishes separate SAs between itself and each endpoint.
</t>
<t>
Middlebox: A SIP network device that modifies SDP media address:port
information in order to steer or anchor media flows described in
the SDP, including TCP and TLS connections used for MSRP communication,
through a media proxy function controlled by the SIP endpoint.
In most cases the media proxy function relays the MSRP messages
without modification, while in some circumstances it acts as a
MSRP B2BUA. Other SIP related functions, such as related to
routing, modification of SIP information etc, performed by the
Middlebox, and whether it acts a SIP B2BUA or not, is outside
the scope of this document. Section 5 describes additional
assumptions regarding how the Middlebox handles MSRP in order to
support the extension defined in this document.
</t>
<t>
Media anchor: An entity that performs media anchoring inserts itself
in the media path of a media communication session between two
entities. The entity will receive, and forward, the media sent
between the entities.
</t>
<t>
This document reuses the terms answer, answerer, offer and offerer as
defined in RFC 3264.
</t>
</section>
<section title="Applicability Statement" toc="default">
<t>
This document defines a Message Session Relay Protocol (MSRP)
extension, Connection Establishment for Media Anchoring (CEMA).
Support of the extension is optional. The extension allows
Middleboxes to anchor the MSRP connection, without the need for
Middleboxes to modify the MSRP messages, and thus also enables a
secure end-to-end MSRP communication in networks where such Middleboxes
are deployed. The document also defines a Session Description Protocol
(SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate
support of the CEMA extension.
</t>
<t>
The CEMA extension is primarily intended for MSRP endpoints that
operate in networks in which Middleboxes that want to anchor media
connections are deployed, without the need for the Middleboxes to
enable MSRP B2BUA functionality. An example of such network is the
IP Multimedia Subsystem (IMS) defined by the 3rd Generation
Partnership Project (3GPP), which also has the capability for all
endpoints to use Name-based TLS Authentication. The extension is also
useful for other MSRP endpoints operating in other networks, but that
communicate with MSRP endpoints in networks with such Middleboxes,
unless there is a gateway between the networks that by default always
enable MSRP B2BUA functionality.
</t>
<t>
This document assumes certain behaviors on the part of Middleboxes, as
described in <xref format="default" pageno="false" target="S.assumption"/>.
These behaviors are not standardized. If Middleboxes do not behave as assumed,
then the CEMA extension does not add any value over base MSRP behavior. MSRP
endpoints that support CEMA are required to use RFC 4975 behavior in cases
where they detect that the CEMA extension cannot be enabled.
</t>
</section>
<section title="Connection Establishment for Media Anchoring Mechanism" toc="default">
<section title="General" toc="default">
<t>
This section defines how an MSRP endpoint that supports the CEMA
extension generates SDP offers and answers for MSRP, and which SDP
information elements the MSRP endpoint uses when creating the TCP
or TLS connection for sending and receiving MSRP messages.
</t>
<t>
Based on the procedures described in sections 4.2 and 4.3, in the
following cases the CEMA extension will not be enabled, and there will
be a fallback to the MSRP connection establishment procedures defined
in RFC 4975 and RFC 4976:
</t>
<t>
- A non-CEMA-enabled MSRP endpoint becomes "active"
<xref format="default" pageno="false" target="RFC6135" /> (no matter whether it uses
a relay for its MSRP communication or not), as it will always establish
the MSRP connection using the SDP 'path' attribute, which contains the address
information of the remote MSRP endpoint, instead of using the SDP c/m-line which contains
the address information of the Middlebox.
</t>
<t>
- A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication
becomes "passive" <xref format="default" pageno="false" target="RFC6135" />,
as it cannot be assumed that the MSRP endpoint inserts the address
information of the relay in the SDP c/m-line.
</t>
<t>
- A CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes
"active", since if it adds the received SDP c/m-line address information to the ToPath
header field of the MSRP message (in order for the relay to establish the MSRP connection
towards the Middlebox), the session matching <xref format="default" pageno="false" target="RFC4975" />
performed by the remote MSRP endpoint will fail.
</t>
</section>
<section anchor="S.offerer" title="MSRP SDP Offerer Procedures" toc="default">
<t>
When a CEMA-enabled offerer sends an SDP offer for MSRP, it
generates the SDP offer according to the procedures in RFC 4975. In
addition, the offerer follows RFC 4976 if it is using a relay for
MSRP communication. The offerer also performs the following
additions and modifications:
</t>
<t>
1. The offerer MUST include an SDP 'msrp-cema' attribute in
the MSRP media description of the SDP offer.
</t>
<t>
2. If the offerer is not using a relay for MSRP communication,
it MUST include an SDP 'setup' attribute in the MSRP media
description of the SDP offer, according to the procedures in RFC
6135 <xref format="default" pageno="false" target="RFC6135" />.
</t>
<t>
3. If the offerer is using a relay for MSRP communication, it
MUST, in addition to including the address information of the relay in
the topmost SDP 'path' attribute, also include the address information of
the relay, 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 'setup:actpass' attribute in the MSRP media description of the
SDP offer.
</t>
<t>
When the offerer receives an SDP answer, if the MSRP media
description of the SDP answer does not contain an SDP 'msrp-cema'
attribute, and if any of the following criteria below is met, the offerer
MUST fallback to RFC 4975 behavior, by sending a new SDP offer according
to the procedures in RFC 4975 and RFC 4976. The new offer MUST NOT
contain an SDP 'msrp-cema' attribute.
</t>
<t>
1. The SDP c/m-line address information associated with the MSRP
media description does not match <xref format="default"
pageno="false" target="S.address"/> the information in the MSRP URI
of the 'path' attribute(s) (in which case is assumed that
the SDP c/m-line contains the address to a Middlebox), and the MSRP
endpoint will become "passive" (if the MSRP media description of
the SDP answer contains an SDP 'setup:active' attribute).
</t>
<t>
NOTE: If an MSRP URI contains a domain name, it needs to be resolved
into an IP address and port before it is checked against the SDP c/m-line
address information, in order to determine whether the address
information matches.
</t>
<t>
2. The offerer uses a relay for its MSRP communication,
the SDP c/m-line address information associated with the MSRP
media description does not match the information in the MSRP URI
of the SDP 'path' attribute(s) (in which case is assumed that
the SDP c/m-line contains the address to a Middlebox), and the
offerer will become "active" (either by default or if the
MSRP media description of the SDP answer contains an SDP
'setup:passive' attribute).
</t>
<t>
3. The remote MSRP endpoint, acting as an answerer, uses a relay for
its MSRP communication, the SDP c/m-line address information associated
with the MSRP media description does not match the information in the
MSRP URI of the SDP 'path' attributes (in which case is assumed that
the SDP c/m-line contains the address to a Middlebox), and the MSRP
offerer will become "active" (either by default or if the MSRP media
description of the SDP answer contains an SDP 'setup:passive' attribute).
</t>
<t>
NOTE: As described in section 5, in the absence of the SDP 'msrp-cema'
attribute in the new offer, it is assumed that a Middlebox will act as
an MSRP B2BUA in order to anchor MSRP media.
</t>
<t>
The offerer can send the new offer within the existing early
dialog <xref format="default" pageno="false" target="RFC3261" />, or
it can terminate the early dialog and establish a new dialog by
sending the new offer in a new initial INVITE request.
</t>
<t>
The offerer MAY choose to terminate the session establishment
if it can detect that a Middlebox acting as an MSRP B2BUA is not the
desired remote MSRP endpoint.
</t>
<t>
If the answerer uses a relay for its MSRP communication, and the
SDP c/m-line address information associated with the MSRP media
description matches one of the SDP 'path' attributes, it is assumed
that there is no Middlebox in the network. In that case the offerer
MUST fallback to RFC 4975 behavior, but it does not need to send a
new SDP offer.
</t>
<t>
In other cases, where none of the criteria above is met, and where the MSRP
offerer becomes "active", it MUST use the SDP c/m-line for establishing the
MSRP TCP connection. If the offerer becomes "passive", it will wait for
the answerer to establish the TCP connection, according to the
procedures in RFC 4975.
</t>
</section>
<section title="MSRP SDP Answerer Procedures" toc="default">
<t>
If the MSRP media description of the SDP offer does not contain an
SDP 'msrp-cema' attribute, and the SDP c/m-line address information
associated with the MSRP media description does not match the
information in the MSRP URI of the SDP 'path' attribute(s),
the answerer MUST either reject the
offered MSRP connection (by using a zero port value number in the generated
SDP answer), or reject the whole SDP offer carrying SIP request with a
488 Not Acceptable Here <xref format="default" pageno="false" target="RFC3261" />
response.
</t>
<t>
NOTE: The reasons for the rejection is that the answerer assumes that
a middlebox, that do not support the CEMA extension, has modified the c/m-line
address information of the SDP offer, without enabling MSRP B2BUA functionality.
</t>
<t>
NOTE: If an MSRP URI contains a domain name, it needs to be resolved
into an IP address and port before it is checked against the SDP c/m-line
address information, in order to determine whether the address
information matches.
</t>
<t>
If any of the criteria below is met, the answerer MUST fallback
to RFC 4975 behavior and generate the associated SDP answer according
to the procedures in RFC 4975 and RFC 4976. The answerer MUST
NOT insert an SDP 'msrp-cema' attribute in the MSRP media description
of the SDP answer.
</t>
<t>
1. Both MSRP endpoints are using relays for their MSRP communication.
The answerer can detect if the remote MSRP endpoint, acting as an
offerer, is using a relay for its MSRP communication if the MSRP
media description of the SDP offer contains multiple SDP 'path' attributes.
</t>
<t>
2. The offerer uses a relay for its MSRP communication, and
will become "active" (either by default or if the MSRP media
description of the SDP offer contains an SDP 'setup:active'
attribute). Note that a CEMA-enabled offerer would
include an SDP 'setup:actpass' attribute in the SDP offer, as
described in Section 4.2.
</t>
<t>
3. The answerer uses a relay for MSRP communication and is not
able to become "passive" (if the MSRP media description of the offer
contains an SDP 'setup:passive' attribute. Note that an offerer
is not allowed to include an SDP 'setup:passive' attribute in an SDP
offer, as described in RFC 6135.
</t>
<t>
In all other cases, the answerer generates the associated SDP
answer according to the procedures in RFC 4975 and RFC 4976, with the
following additions and modifications:
</t>
<t>
1. The answerer MUST include an SDP 'msrp-cema' attribute in
the MSRP media description of the SDP answer.
</t>
<t>
2. If the answerer is not using a relay for MSRP communication,
it MUST include an SDP 'setup' attribute in the MSRP media
description of the answer, according to the procedures in RFC 6135.
</t>
<t>
3. If the answerer is using a relay for MSRP communication, it
MUST, in addition to including the address information of the relay in
the topmost SDP 'path' attribute, also include the address information of
the relay, rather than the address information of itself, in the SDP
c/m-line associated with the MSRP media description. In addition, the
answerer MUST include an SDP 'setup:passive' attribute in the MSRP
media description of the SDP answer.
</t>
<t>
If the answerer included an SDP 'msrp-cema' attribute in the
MSRP media description of the SDP answer, and if the answerer
becomes "active", it MUST use the received SDP c/m-line for
establishing the MSRP TCP or TLS connection. If the answerer becomes
"passive", it will wait for the offerer to establish the
MSRP TCP or TLS connection, according to the procedures in RFC 4975.
</t>
</section>
<section anchor="S.address" title="Address Information Matching" toc="default">
<t>
When comparing address information in the SDP c/m-line and an MSRP
URI, for address and port equivalence, the address and port values are
retrieved in the following ways:
</t>
<t>
- SDP c/m-line address information: The IP address is retrieved from
the SDP c- line, and the port from the associated SDP m- line for MSRP.
</t>
<t>
- In case the SDP c- line contains a Fully Qualified Domain Name (FQDN), the
IP address is retrieved using DNS.
</t>
<t>
- MSRP URI address information: The IP address and port are retrieved from
the authority part of the MSRP URI.
</t>
<t>
- In case the authority part of the MSRP URI contains a Fully Qualified
Domain Name (FQDN), the IP address is retrieved using DNS, according
to the procedures in section 6.2 of RFC 4975.
</t>
<t>
NOTE: According to RFC 4975, the authority part of the MSRP URI must always
contain a port.
</t>
<t>
Before IPv6 addresses are compared for equivalence, they need to be converted
into the same representation, using the mechanism defined in RFC 5952
<xref format="default" pageno="false" target="RFC5952" />.
</t>
<t>
NOTE: In case the DNS returns multiple records, each needs to be compared against
the SDP c/m- line address information, in order to find at least one match.
</t>
<t>
NOTE: If the authority part of the MSRP URI contains special characters, they are
handled according to the procedures in section 6.1 of RFC 4975.
</t>
</section>
<section title="Usage With the Alternative Connection Model" toc="default">
<t>
An MSRP endpoint that supports the CEMA extension MUST support the
mechanism defined in RFC 6135, as it extends the number of scenarios
where one can use the CEMA extension. An example is where an MSRP
endpoint is using a relay for MSRP communication, and it needs to be
"passive" in order to use the CEMA extension, instead of doing a
fallback to RFC 4975 behavior.
</t>
</section>
</section>
<section title="The SDP 'msrp-cema' attribute" toc="default">
<section title="General" toc="default">
<t>
The SDP 'msrp-cema' attribute is used by MSRP entities to indicate
support of the CEMA extension, according to the procedures in
Sections 4.2 and 4.3.
</t>
</section>
<section title="Syntax" toc="default">
<t>
This section describes the syntax extensions to the ABNF syntax
defined in RFC 4566 required for the SDP 'msrp-cema' attribute.
The ABNF defined in this specification is conformant to
RFC 5234 <xref format="default" pageno="false" target="RFC5234" />.
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[
attribute /= msrp-cema-attr
;attribute defined in RFC 4566
msrp-cema-attr = "msrp-cema"
]]></artwork>
</figure>
</section>
</section>
<section anchor="S.assumption" title="Middlebox Assumptions" toc="default">
<section title="General" toc="default">
<t>
This document does not specify explicit Middlebox behavior, even
though Middleboxes enable some of the procedures described here.
However, as MSRP endpoints are expected to operate in networks
where Middleboxes that want to anchor media are present,
this document makes certain assumptions regarding to how such
Middleboxes behave.
</t>
</section>
<section title="MSRP Awareness" toc="default">
<t>
In order to support interoperability between UAs that support the
CEMA extension and UAs that do not support the extension, the
Middlebox is MSRP aware. This means that it implements MSRP B2BUA
functionality. The Middlebox enables that functionality in cases
where the offerer does not support the CEMA extension. In
cases where the SDP offer indicates support of the CEMA extension,
the Middlebox can simply modify the SDP c/m-line address information
for the MSRP connection.
</t>
<t>
In cases where the Middlebox enables MSRP B2BUA functionality, it
acts as an MSRP endpoint. If it does not use the CEMA procedures
it will never forward the SDP 'msrp-cema' attribute in SDP offers
and answers.
</t>
<t>
If the Middlebox does not implement MSRP B2BUA functionality, or does
not enable it when the SDP 'msrp-cema' attribute is not present in the
SDP offer, CEMA-enabled MSRP endpoints will in some cases be unable to
interoperate with non-CEMA-enabled endpoints across the Middlebox.
</t>
</section>
<section title="TCP Connection Reuse" toc="default">
<t>
Middleboxes do not need to parse and modify the MSRP payload when
endpoints use the CEMA extension. A Middlebox that does not parse
the MSRP payload probably will not be able to reuse TCP connections
for multiple MSRP sessions. Instead, in order to associate an MSRP message
with a specific session, the Middlebox often assigns a unique local
address:port combination for each MSRP session. Due to this, between two
Middleboxes there might be a separate connection for each MSRP session.
</t>
<t>
If the Middlebox does not assign a unique address:port combination for
each MSRP session, and does not parse MSRP messages, it might end up forwarding
MSRP messages towards the wrong destination.
</t>
</section>
<section title="SDP Integrity" toc="default">
<t>
This document assumes that Middleboxes are able to modify
the SDP address information associated with the MSRP media, and
that they are able to modify the SDP address information associated
with the MSRP media.
</t>
<t>
NOTE: Eventhough the CEMA extension as such works with end-to-end SDP protection,
the main advantage of the extension is in networks where Middleboxes are deployed.
</t>
<t>
If the Middlebox is unable to modify SDP payloads due to end-to-end
integrity protection, it will be unable to anchor MSRP media as the
SIP signaling would fail due to integrity violations.
</t>
</section>
<section title="TLS" toc="default">
<t>
When UAs use the CEMA extension, this document assumes that Middleboxes
relay MSRP media packets at the transport layer. The TLS handshake and resulting
security association (SA) can be established peer-to-peer between the MSRP endpoints.
The Middlebox will see encrypted MSRP media packets, but is unable to
inspect the clear text content.
</t>
<t>
When UAs fall back to RFC 4975 behavior Middleboxes act as TLS B2BUAs.
The Middlebox decrypts MSRP media packets received from one MSRP endpoint, and
then re-encrypts them before sending them toward the other MSRP endpoint.
Middleboxes can inspect and modify the MSRP message content.
</t>
</section>
</section>
<section anchor="sec-security" title="Security Considerations" toc="default">
<section anchor="sec-security-gen" title="General" toc="default">
<t>
Unless otherwise stated, the security considerations in RFC 4975 and RFC 4976 still
apply. This section only describes additions and changes introduced by the CEMA
extension.
</t>
<t>
In deployments where Middleboxes are always used, which is the main use case
for the CEMA extension, the CEMA extension increases the security by enabling the
use of end-to-end TLS between the two endpoints. If the key management does not
depend on trust in the signaling plane, this greatly increases the security. If
the key management depends on trust in the signaling plane, the Middlebox is by
definition trusted, but the security is still increased as the cleartext is not
available in the Middlebox.
</t>
</section>
<section anchor="sec-security-mitma" title="Man-in-the-Middle Attacks" toc="default">
<t>
If TLS is not used to protect MSRP, the CEMA extension might make it easier for a
man-in-the-middle to transparently insert itself in the communication between MSRP
endpoints in order to monitor or record unprotected MSRP communication. This can be
mitigated by the use of TLS. It is therefore RECOMMENDED to use TLS <xref format="default"
pageno="false" target="RFC5246" />. It is also recommended to use TLS e2e, which CEMA
enables even in the case of Middleboxes. For backward compatibility, a CEMA-enabled
MSRP endpoint MUST implement TLS.
</t>
</section>
<section anchor="sec-security-tlswom" title="TLS Usage without Middleboxes" toc="default">
<t>
If TLS is use without Middleboxes, the security considerations in RFC 4975 and RFC 4976
still apply unchanged. Note that this is not the main use case for the CEMA extension.
</t>
</section>
<section anchor="sec-security-tlswm" title="TLS Usage with Middleboxes" toc="default">
<t>
This is the main use case for the CEMA extension; the endpoints expect one or more
Middlebox.
</t>
<t>
The CEMA extension supports the usage of both name-based authentication and fingerprint
based authentication for TLS in the presence of Middleboxes. The use of fingerprint based
authentication requires signaling integrity protection. This can e.g. be hop-by-hop
cryptographic protection or cryptographic access protection combined with physical trust
in other parts of the signaling plane. As stated in section 6.4, this document assumes
that Middleboxes are able to modify the SDP address information associated with the MSRP
media, and that they are able to modify the SDP address information associated with the
MSRP media.
</t>
<t>
If a Middlebox acts as a TLS B2BUA, the security considerations are the same as without the
CEMA extension. In such case the Middlebox acts as TLS endpoints.
</t>
<t>
If a Middlebox does not act as a TLS B2BUA, TLS is e2e and the Middlebox just forwards the
TLS packets. This requires that both peers support the CEMA extension.
</t>
<t>
If fingerprint based authentication is used, the MSRP endpoints might not be able to decide
whether the Middlebox acts as a TLS B2BUA or not. But this is not an issue as the signaling
network is considered trusted by the endpoint (a requirement to use fingerprint based authentication).
</t>
</section>
<section anchor="sec-security-ackm" title="Authentication, Credentials and Key Management" toc="default">
<t>
One issue with usage of TLS (not specific to CEMA) is the availability of a PKI. Endpoints
can always provide self-signed certificates. However, this relies on that the SDP signaling is
integrity protected, which may not always be the case.
</t>
<t>
Therefore, it addition to the authentication mechanisms defined in RFC 4975, it is RECOMMENDED
that a CEMA-enabled MSRP endpoint also supports self-signed certificates together Certificate
Management Service <xref format="default" pageno="false" target="RFC6072" />, to which it publishes
its self-signed certificate and from which it fetches on demand the self-signed certificates of
other endpoints.
</t>
<t>
Alternate key distribution mechanisms, such as DANE [DANE], PGP <xref format="default" pageno="false"
target="RFC6091" />, MIKEY-TICKET <xref format="default" pageno="false" target="RFC6043" /> or some
other technology, might become ubiquitous enough to solve the key distribution problem in the future.
</t>
<t>
One of the target deployments for CEMA is the 3GPP IMS SIP network. In this environment authentication
and credential management is less of a problem as the SDP signaling is mostly considered trusted, service
providers provision signed certificates or manage signed certificates on behalf of their subscribers,
and MIKEY-TICKET is available. Some of these options require trusting the service provider, but those
issues are beyond the scope of this document.
</t>
</section>
<section anchor="sec-security-endtls" title="Endpoint procedures for TLS negotiation" toc="default">
<t>
The CEMA extension does not change the endpoint procedures for TLS negotiation. As in RFC 4975, the
MSRP endpoint uses the negotiation mechanisms in SDP and then the TLS handshake to agree on a mechanisms
and algorithms that both support. The mechanisms can be divided in three different security levels:
</t>
<t>
- MSRPS: Security Mechanisms that does not rely on trusted signaling such as name based authentication
</t>
<t>
- MSRPS: Mechanisms that do rely on trusted signaling such as fingerprint based authentication
</t>
<t>
- MSRP: Unprotected
</t>
<t>
If the endpoint uses security mechanisms that does not rely on trusted signaling the endpoint can detect if a
Middlebox is inserted. It is therefore RECOMMENDED to use such a mechanism.
</t>
<t>
If the endpoint uses security mechanisms that rely on trusted signaling the endpoint may not be able to detect
if a Middlebox is inserted (by the trusted network operator). To be able to eavesdrop a Middlebox must do an
active "attack" on the setup signaling. A Middlebox cannot insert itself at a later point.
</t>
<t>
If Unprotected MSRP is used, the endpoint cannot detect if a Middlebox is inserted and Middleboxes may be
inserted at any time during the session.
</t>
<t>
The mechanism in RFC 6072 <xref format="default" pageno="false" target="RFC6072" /> provides end-to-end
security without relying on trust in the signaling, and eases the use and deployment of name based
authentication.
</t>
<t>
The procedures for choosing and offering name based authentication, fingerprint based authentication, and
unprotected MSRP as described in RFC 4975 still apply.
</t>
</section>
<section anchor="sec-security-fpauth" title="Fingerprint Based Authentication" toc="default">
<t>
If the endpoint cannot use a key management protocol that does not rely on trust in the signaling
such as name based authentication, the only alternative is fingerprint based authentication.
</t>
<t>
The use of fingerprint based authentication requires integrity protection of the signaling plane. This
can e.g. be end-to-end cryptographic protection, hop-by-hop cryptographic protection, or cryptographic
access protection combined with physical trust in other parts of the signaling plane. Unless cryptographic
end-to-end SDP integrity protection or encryption is used this may be hard for the endpoint to decide. In
the end it is up to the endpoint to decide whether the signaling path is trusted or not.
</t>
<t>
How this decision is done is implementation specific, but normally signaling over the internet SHOULD
NOT be trusted. Signaling over a local or closed network MAY be trusted. Such networks can e.g. be a
closed enterprise network or a network operated by an operator that the end user trusts. In e.g. IMS
the signaling traffic in the access network is integrity protected and the traffic is routed over a
closed network separated from the Internet. If the network is not trusted the endpoints SHOULD NOT use
fingerprint authentication.
</t>
<t>
It should however be noted that using fingerprint based authentication over an insecure network increases
the security compared to unencrypted MSRP as this makes it harder to perform an man-in-the-middle attack.
Such an attack needs to be done to both the signaling and the media plane, which may be separated. It does
not however give any guarantees that such a man-in-the-middle attack is not taking place. A client using
DTLS-SRTP <xref format="default" pageno="false" target="RFC5764" /> for VoIP media security may wish to
use fingerprint based authentication also for MSRP media security.
</t>
<t>
MSRPS with fingerprint based authentication is vulnerable to attacks due to vulnerabilities in the SIP
signaling. If there are weaknesses in the integrity protections on the SIP signaling, an attacker may
insert malicious middleboxes to alter, record, or otherwise harm the media. With insecure signaling,
it can be difficult for an endpoint to even be aware the remote endpoint has any relationship to the
expected endpoint. Securing the SIP signaling does not solve all problems. For example, in a SIPS
environment, the endpoints have no cryptographic way of validating that one or more SIP Proxies in the
proxy chain are not, in fact, malicious.
</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<section title="IANA Registration of the SDP 'msrp-cema' attribute" toc="default">
<t>
This document instructs IANA to add a attribute to the 'att-field
(media level only)' registry of the SDP parameters registry, according
to the information provided in this section.
</t>
<t>
This section registers a new SDP attribute, 'msrp-cema'. The
required information for this registration, as specified in RFC 4566,
is:
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com
Attribute name: msrp-cema
Type of attribute: media level
Purpose: This attribute is used to indicate support of
the MSRP Connection Establishment for Media
Anchoring (CEMA) extension defined in
RFC XXXX. When present in an MSRP media
description of an SDP body, it indicates
that the creator of the SDP supports the CEMA
mechanism.
Values: The attribute does not carry a value
Charset dependency: none
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec-acks" title="Acknowledgements" toc="default">
<t>
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, Saul Ibarra Corretge,
Cullen Jennings, Adrian Georgescu and Miguel Garcia for their guidance
and input in order to produce this document.
</t>
<t>
Thanks to John Mattsson for his help to restructure the Security
Considerations section, based on the feedback from IESG.
</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
<t>Changes from draft-ietf-simple-msrp-cema-04<list style="symbols">
<t>Changes based on additional IESG comments from Stephen Farrell.</t>
<t>- 'Media anchor' definition added.</t>
<t>- TLS reference made normative.</t>
<t>- MIKEY-TICKET recommendation removed.</t>
<t>- Editorial clarifications.</t>
</list>
</t>
<t>Changes from draft-ietf-simple-msrp-cema-03<list style="symbols">
<t>Security Considerations sections re-written based on IESG comments.</t>
<t>Changes based on IESG comments from Peter Saint-Andre.</t>
<t>Changes based on IESG comments from Robert Sparks.</t>
<t>Changes based on IESG comments from Stephen Farrell.</t>
<t>Changes based on IESG comments from Pete Resnick.</t>
</list>
</t>
<t>Changes from draft-ietf-simple-msrp-cema-02<list style="symbols">
<t>Changes based on WGLC comments.</t>
<t>- Editorial changes based on comments from Nancy Greene.</t>
<t>- Editorial changes based on comments from Saul Ibarra Corretge.</t>
<t>- Editorial changes based on comments from Christian Schmidt.</t>
<t>- Editorial changes based on comments from Miguel Garcia.</t>
<t>Changes based on MMUSIC SDP impact review.</t>
<t>- Editorial changes based on comments from Miguel Garcia.</t>
</list>
</t>
<t>Changes from draft-ietf-simple-msrp-cema-01<list style="symbols">
<t>Changes based on comment from Ben Campbell.</t>
<t>- TLS B2BUA added to definitions section.</t>
<t>- Middlebox added.</t>
<t>- Editorial changes.</t>
</list>
</t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-13<list style="symbols">
<t>Changed the draft name, as was suggested by our AD and work
group.</t>
<t>Clean up language use, clarify language, and clean up editorial
and style issues.</t>
<t>Formally defined an MSRP B2BUA.</t>
</list>
</t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-12 <list
style="symbols">
<t>Extension name changed to Connection Establishment for Media
Anchoring (CEMA).</t>
<t>Middlebox definition added.</t>
<t>ALG terminology replaced with Middlebox.</t>
<t>SDP attribute name changed to a=msrp-cema.</t>
<t>Applicability Statement section expanded.</t>
<t>Re-structuring of MSRP Answerer section.</t>
<t>Changes based on comments from Saúl Ibarra Corretgé
(1406111).</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-11 <list
style="symbols">
<t>Modification of the sessmatch mechanism.</t>
<t>- Extension name changed to Alternative Connection Establishment
(ACE)</t>
<t>- Session matching procedure no longer updated.</t>
<t>- SDP c/m-line used for MSRP TCP connection.</t>
<t>- sessmatch option-tag removed.</t>
<t>- a=msrp-ace attribute defined.</t>
<t>- Support of RFC 6135 mandatory.</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-10 <list
style="symbols">
<t>Sessmatch option-tag added, based on WG discussions and
concensus.</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-08 <list
style="symbols">
<t>OPEN ISSUE regarding the need for a sessmatch option-tag
removed.</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-07 <list
style="symbols">
<t>Sessmatch defined as an MSRP extension, rather than MSRP
update</t>
<t>Additional security considerations text added</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.4975"?>
<?rfc include="reference.RFC.4976"?>
<?rfc include="reference.RFC.5234"?>
<?rfc include="reference.RFC.5246"?>
<?rfc include="reference.RFC.6072"?>
<?rfc include="reference.RFC.6135"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3724"?>
<?rfc include="reference.RFC.5764"?>
<?rfc include="reference.RFC.5952"?>
<?rfc include="reference.RFC.6043"?>
<?rfc include="reference.RFC.6091"?>
<reference anchor="GPP23228">
<front>
<title>IP Multimedia Subsystem (IMS); Stage 2</title>
<author>
<organization>3GPP</organization>
</author>
<date day="13" month="June" year="2011" />
</front>
<seriesInfo name="3GPP TS" value="23.228 10.5.0" />
<format target="http://www.3gpp.org/ftp/Specs/html-info/23228.htm" type="HTML" />
</reference>
<reference anchor="DANE">
<front>
<title>DNS-based Authentication of Named Entities Work Group</title>
<author>
<organization></organization>
</author>
<date />
</front>
<format target="https://datatracker.ietf.org/wg/dane/charter/" type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:52:58 |