One document matched: draft-ietf-simple-msrp-cema-01.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-01.txt" obsoletes="" extends="4975" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="MRSP">
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="2011" />
<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 an 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, a=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, lawful intercept, 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. Since the active MSRP UA
establishes the MSRP TCP or TLS connection based on the MSRP URI of the SDP a=path
attribute, this means that the MSRP connection will not, unless the Middlebox also
modifies the MSRP URI of the topmost SDP a=path attribute, be routed through the
Middlebox. In many scenarios this will prevent the MSRP connection from being
established. In addition, if the Middlebox modifies the MSRP URI of the SDP a=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 a=path attribute, will fail. Also the matching will fail if Middleboxes
modify the address information in the MSRP URI of the SDP a=path attribute.
</t>
<t>
The only way to achieve interoperability in this situation is for the Middlebox
to act as a 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 without a need for the Middleboxes to be a 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 it does 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 fully backward compatible. 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 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 TLS certificate and sends a certificate fingerprint
in SDP.
</t>
<t>
Name Based TLS Authentication: An MSRP endpoint that 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.
</t>
<t>
B2BUA: This is an abbreviation for back-to-back user agent.
</t>
<t>
MSRP B2BUA: A network element that terminates a 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 a 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>
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>
</section>
<section title="Applicability Statement" toc="default">
<t>
This document defines an 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, a=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>
</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 what SDP
information elements the MSRP endpoint uses when creating the TCP
or TLS connection for the MSRP messages.
</t>
<t>
In the following cases, where there is a Middlebox in the network, the
CEMA extension can not be used, 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".
</t>
<t>
- A non-CEMA-enabled MSRP endpoint uses a relay for its MSRP communication.
</t>
<t>
- A CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes "active".
</t>
</section>
<section anchor="S.offerer" title="MSRP Offer Procedures" toc="default">
<t>
When a CEMA-enabled MSRP endpoint sends an SDP offer for MSRP, it
generates the SDP offer according to the procedures in RFC 4975. In
addition, the endpoint follows RFC 4976 if it is using a relay for
MSRP communication. The endpoint also performs the following
additions and modifications:
</t>
<t>
1. The MSRP endpoint MUST include an SDP a=msrp-cema attribute in
the MSRP media description of the SDP offer.
</t>
<t>
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 <xref format="default" pageno="false" target="RFC6135" />.
</t>
<t>
3. If the MSRP endpoint is using a relay for MSRP communication, it
MUST include the address information of 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:actpass attribute in the MSRP media description of the
SDP offer.
</t>
<t>
When the MSRP endpoint receives the associated SDP answer, the SDP
answer indicates that the remote MSRP endpoint accepted the offered
MSRP media if the port number of the MSRP media description is not zero.
</t>
<t>
If the MSRP media description of the SDP answer does not contain an
SDP a=msrp-cema attribute, the MSRP endpoint MUST check the criteria below.
If either or both of the criteria is met, the MSRP endpoint 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 a=msrp-cema attribute.
</t>
<t>
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").
</t>
<t>
2. The MSRP media description contains multiple SDP a=path
attributes, indicating the use of MSRP relays.
</t>
<t>
NOTE: In the absence of the SDP a=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 MSRP endpoint MAY choose to terminate the session establishment
if it can detect that a Middlebox acting as a MSRP B2BUA is not the
desired remote endpoint.
</t>
<t>
The MSRP endpoint 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>
In all other cases, where the MSRP endpoint becomes "active", it MUST
use the SDP c/m-line for establishing the MSRP TCP or TLS connection.
If the MSRP endpoint becomes "passive", it will wait for the remote MSRP
endpoint to establish the connection, according to the procedures
in RFC 4975.
</t>
</section>
<section title="MSRP Answer Procedures" toc="default">
<t>
If any of the criteria below is met, 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-cema attribute in the MSRP media description
of the SDP answer.
</t>
<t>
1. Both MSRP endpoints are using relays for MSRP communication. An
endpoint can detect the remote MSRP endpoint is using a relay for
MSRP communication if the MSRP media description of the SDP offer
contains multiple SDP a=path attributes.
</t>
<t>
2. The remote MSRP endpoint uses a relay for MSRP communication, and
will become "active" either by default or if the MSRP media
description of the SDP offer contains an SDP a=setup:active
attribute. Note that a CEMA-enabled endpoint would
include an SDP a=setup:actpass attribute in the SDP offer, as
described in Section 4.2.
</t>
<t>
3. The MSRP endpoint uses a relay for MSRP communication and is not
able to become "passive". The indication for this is the MSRP
media description of the offer contains an SDP a=setup:passive
attribute. Note that an MSRP endpoint is now allowed to include an
SDP a=setup:passive attribute in an SDP offer, as described in RFC 6135.
</t>
<t>
4. The MSRP media description of the SDP offer does not contain an
SDP a=msrp-cema attribute, 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 if the MSRP media description of the SDP offer
contains an SDP a=setup:active attribute.
</t>
<t>
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:
</t>
<t>
1. The MSRP endpoint MUST include an SDP a=msrp-cema attribute in
the MSRP media description of the SDP answer.
</t>
<t>
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.
</t>
<t>
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 answer.
</t>
<t>
If the MSRP endpoint included an SDP a=msrp-cema 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 TLS connection. If the MSRP endpoint becomes
"passive", it will wait for the remote MSRP endpoint to establish the
TCP or TLS connection, according to the procedures in 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 a 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 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 remote endpoint 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>
</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.
</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. Middleboxes
cannot be deployed in environments that require end-to-end SDP
protection using SIP identity <xref format="default" pageno="false"
target="RFC4916" />.
</t>
</section>
<section title="TLS" toc="default">
<t>
When UAs use the CEMA extension, Middleboxes relay 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 Middlebox will see encrypted MSRP media packets, but is unable to
inspect the clear text content.
</t>
<t>
When UAs fallback to RFC 4975 behavior Middleboxes act as TLS B2BUAs,
meaning that separate SAs are established between the Middlebox and each MSRP
endpoint. 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-mitm" title="Man in the Middle" toc="default">
<t>
In some cases, where MSRP B2BUA functionality does not need to be
enabled, the CEMA 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 CEMA extension or not.
It would thus require the MiTM to terminate the TCP/TLS/MSRP
connection in both directions. MSRP endpoints SHOULD use encrypted
channels, if possible. For backward compability, a CEMA-enabled MSRP
endpoint MUST implement TLS.
</t>
</section>
<section anchor="sec-security-tls" title="TLS Usage" toc="default">
<t>
The CEMA extension supports the usage of name-based authentication
for TLS in the presence of Middleboxes.
</t>
<t>
If a Middlebox acts as a TLS B2BUA, MSRP endpoints will be able to
use fingerprint based authentication for TLS, no matter if they
support the CEMA extension or not. In such cases, as the Middlebox
acts as TLS endpoints, MSRP endpoints might be given an incorrect
impression that there is an end-to-end security association (SA)
between the MSRP endpoints.
</t>
<t>
If a Middlebox 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, it is RECOMMENDED
that a CEMA-enabled MSRP endpoint also supports an authentication
mechanism that does not rely on peer-to-peer SDP integrity.
</t>
<t>
It is RECOMMENDED that an MSRP endpoint support one of the following
authentication mechanisms:
</t>
<t>
1. TLS certificates together with support of interacting with a
Certificate Management Service <xref format="default" pageno="false"
target="RFC6072" />, to which it publishes the public version of its
own self-signed certificate and from which it fetches on demand the
public certificates of other endpoints.
</t>
<t>
2. TLS-PSK managed by MIKEY-TICKET Based Key Management and Key
Management Service <xref format="default" pageno="false" target="RFC6043" />.
Note that 3GPP has specified the MIKEY-TICKET based Key Management and Key
Management Service authentication mechanism for the IP Multimedia Subsystem (IMS).
Thus it will be available in that environment.
</t>
<t>
When an MSRP endpoint generates an SDP offer for MSRPS, 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.
</t>
<t>
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 Middleboxes
present. If that also fails, the MSRP endpoints MUST either:
</t>
<t>
1. Consider the TLS authentication as failed, in accordance with RFC
4975; or
</t>
<t>
2. If something like SIPS protects the SIP signaling between the
MSRP endpoints, use fingerprint based authentication without
requiring peer-to-peer SDP integrity, and thus trust the network
endpoints in the signaling path for SDP integrity.
</t>
<t>
As defined in RFC 4975, if TLS authentication fails, the user needs
to be able to decide whether to try to establish an MSRP connection
in the likely scenario of intercepted, altered,
</t>
</section>
<section anchor="sec-security-tls-insec" title="TLS and Insecure Signaling" toc="default">
<t>
One of the side effects of relieving Middleboxes from manipulating message content
is CEMA provides an environment necessary for end-to-end integrity of MSRP media.
However, while CEMA provides a prerequisite for end-to-end integrity, it is not
sufficient.
</t>
<t>
CEMA recommends using an integrity-protected media channel, such as TLS.
As defined in RFC 4975, all MSRP endpoints MUST support TLS. That applies also to
CEMA-enabled endpoints.
</t>
<t>
One issue with usage of TLS is the availability of a certificate infrastructure.
Endpoints can always provide self-signed certificates. However, this is problematic in
that any endpoint can masquerade as another, by providing a self-signed certificate with
the victim's information.
</t>
<t>
One of the target deployments for CEMA is the 3GPP IMS SIP network. In this environment
service providers provision signed certificates or manage signed certificates on behalf of
their subscribers. This does require trusting the service provider, but those issues are
beyond the scope of this document.
</t>
<t>
Alternate key distribution mechanisms, such as DANE <xref target="DANE" />,
PGP <xref target="RFC6091" />, or some other technology, might become ubiquitous enough
to solve the key distribution problem in the future.
</t>
<t>
Even with seemingly end-to-end media integrity, at the time of the publication of this document
there are other vulnerabilities in MSRP, due to vulnerabilities in the SIP signaling. If there
are no integrity protections on the SIP signaling, it is easy to 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 a=msrp-cema Attribute"
toc="default">
<t>This section registers a new SDP attribute, a=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: a=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 sending UA 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, and Adrian Georgescu for their guidance and input in
order to produce this document.</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</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 a 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.6072"?>
<?rfc include="reference.RFC.6135"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3724"?>
<?rfc include="reference.RFC.4916"?>
<?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-22 23:52:26 |