One document matched: draft-ietf-simple-msrp-sessmatch-13.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-sessmatch-13.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>
    <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 MSRP extension, Connection Establishment for Media 
			Anchoring (CEMA). Support of the extension is optional. MSRP endpoints can 
			implement the extension in order to allow MSRP communication in 
			networks where Middleboxes anchor the MSRP connection, without the need for 
			the Middleboxes to enable MSRP B2BUA functionality in most cases. The document 
			also defines a Session Description Protocol (SDP) <xref target="RFC4566" 
			pageno="false" format="default" /> attribute, a=msrp-cema, that can be used 
			by MSRP endpoints to indicate support of the CEMA extension.
		</t>
    </abstract>
</front>
<middle>
    <section title="Introduction" toc="default">
		<t>
			The Message Session Relay Protocol (MSRP) <xref target="RFC4975" pageno="false" format="default" /> is 
			designed to use MSRP relays <xref target="RFC4976" pageno="false" format="default" /> as a means for 
			Network Address Translation (NAT) traversal and policy enforcement.
		</t>
		<t>
			However, many Session Initiation Protocol (SIP) <xref target="RFC3261" pageno="false" format="default" />  
			networks, in which MSRP usage is emerging, also contain Middleboxes, that anchor 
			and control 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) <xref target="3GPP.23.228" pageno="false" format="default" />, 
			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).
		</t>
		<t>
			MSRP, as defined in RFC 4975 <xref target="RFC4975" pageno="false" format="default" /> and RFC 4976 
			<xref target="RFC4976" pageno="false" format="default" />, cannot be anchored when MSRP endpoints communicate 
			with such Middleboxes, unless the Middleboxes implement and enable MSRP Back-To-Back User Agent (B2BUA) functionality for all calls.
			The reason is that Middleboxes 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 Middlebox also modifies the MSRP URI of the 
			topmost SDP a=path attribute be routed through the Middlebox, which in many scenarios will prevent the MSRP
			connection from being established. However, if the Middlebox modifies the MSRP URI of the SDP a=path attribute, 
			then the MSRP URI comparison procedure <xref target="RFC4975" pageno="false" format="default" />, 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 Middleboxes 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 Middlebox, 
			that normally result in negative performance impact.
		</t>
		<t>
			This specification defines an MSRP extension, Connection Establishment for Media Anchoring (CEMA), that in most cases 
			allows MSRP endpoints to communicate with Middleboxes without a need for the Middleboxes to enable MSRP B2BUA  functionality. 
			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), and MSRP endpoints that support the CEMA extension will 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.
		</t>
		<t>	
			The CEMA extension is fully backward compatible. In scenarios where MSRP endpoints that do not support the
			CEMA extension are able to establish MSRP connectivity, 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 
			the address information for the MSRP TCP connection. Once the MSRP TCP connection has been 
			created, an MSRP endpoint that supports the CEMA extension acts 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). 
		</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 target="RFC2119" 
			pageno="false" format="default" />.
		</t>
		<t>
			In this specification the terminology "fingerprint based TLS authentication" and "name based TLS authentication" 
			are used to refer to the two cases where:
		</t>
		<t>
			1.	An MSRP endpoint uses a self-signed TLS certificate and sends a certificate fingerprint in SDP (fingerprint 
			based TLS authentication).
		</t>
		<t>
			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).
		</t>
		<t>
			Middlebox:    Within the scope of this document, Middlebox refers to a network SIP device that modifies SDP 
		   	media address:port information in order to steer (anchor) media flows described in the SDP, including TCP 
			connections used for MSRP communication, through a media proxy function controlled by the SIP device. In most 
			cases the media proxy function relays the MSRP messages without modification, while in other cases it enables 
			MSRP B2BUA functionality. Other SIP related functions (e.g. related to routing, modification of SIP 
			information etc) performed by the SIP device, and whether it acts a SIP B2BUA or not, is outside the scope of the 
			definition. 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 MSRP extension, Connection Establishment for Media 
			Anchoring (CEMA). Support of the extension is optional. MSRP endpoints can 
			implement the extension in order to allow MSRP communication in 
			networks where Middleboxes anchor the MSRP connection, without the need for 
			the Middleboxes to enable MSRP B2BUA functionality in most cases. The document 
			also defines a Session Description Protocol (SDP) <xref target="RFC4566" 
			pageno="false" format="default" /> attribute, a=msrp-cema, that can be used 
			by MSRP endpoints 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). 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 connection for the MSRP messages.
			</t>
		</section>
		<section title="MSRP Offerer Procedures" toc="default">
			<t>
				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:
			</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 
				<xref target="RFC6135" pageno="false" format="default" />.
			</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:actpass attribute in the MSRP media description of the SDP offer. 
			</t>
			<t>
				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-cema attribute, 
				the MSRP endpoint MUST check whether any of the following criteria is fulfilled:
			</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 that MSRP relays are used).
			</t>
			<t>
				If any, or both, of the criteria above is fulfilled, 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>
				NOTE: In the absence of the SDP a=msrp-cema attribute in the new offer, the Middlebox will in all cases have to, 
				in order to be able to anchor MSRP media, enable MSRP B2BUA functionality.
			</t>
			<t>
				NOTE: The MSRP endpoint can send the new offer within the existing early dialog <xref target="RFC3261" 
				pageno="false" format="default" />, 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 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.
			</t>
		</section>
		<section title="MSRP Answerer Procedures" toc="default">
			<t>
				When an MSRP endpoint receives an SDP offer for MSRP, it MUST check the following criteria:
			</t>
			<t>
   				1) Both MSRP endpoints are using relays for MSRP communication.
			</t>
			<t>
   				NOTE: If the MSRP media description of the SDP offer contains contains 
   				multiple SDP a=path attributes, it can be determined that the remote 
   				MSRP endpoint is using a relay for MSRP communication.
			</t>
			<t>
   				2) The remote MSRP endpoint uses a relay for MSRP communciation, and
   				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>
   				NOTE: This case should not occur if the remote MSRP endpoint supports
   				the CEMA extension, as the remote MSRP 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 MSRP media description of the offer
   				contains an SDP a=setup:passive attribute).
			</t>
			<t>
   				NOTE: This case should never occur, as an MSRP entity is not
   				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>
   				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-cema attribute in the MSRP
   				media description of the SDP answer.
			</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 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.
			</t>
		</section>
		<section title="Usage With The Alternative Connection Model" toc="default">
			<t>
				An MSRP endpoint that supports the CEMA extension MUST in addition also support the mechanism defined in 
				RFC 6135, as it extends the number of scenarios where the CEMA extension can be used, and Middleboxes 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 CEMA extension (instead of doing a fallback
				to RFC 4975 behavior.
			</t>
		</section>		
    </section>  

	<section title="Middlebox assumptions" toc="default">
		<section title="General" toc="default">
			<t>
				This document does not specify explicit Middlebox behavior, eventhough some of the procedures will be enabled 
				by Middleboxes. However, as the main reason behind the CEMA extension is to allow MSRP endpoints to communicate 
				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>
				This document assumes that an Middlebox, in order to support interoperability between UAs that support the 
				CEMA extension and UAs that do not support the extension, is MSRP aware, meaning that it implements 
				MSRP B2BUA functionality, and that it enables that functionality in cases where support of the CEMA 
				extension is not indicated. In cases where support of the CEMA extension is indicated by at least 
				one MSRP endpoint, the Middlebox can simply modifies the SDP c/m-line address information for the MSRP 
				connection. However, MSRP communication will work if the Middlebox enables MSRP B2BUA functionality also 
				in such cases.
			</t>
		</section>
		<section title="TCP connection reuse" toc="default">
			<t>
				When the CEMA extension is used, in cases where Middleboxes do not need to enable MSRP B2BUA functionality, 
				the Middleboxes are not required to parse and modify the MSRP payload. An Middlebox 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 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, and therefore can not be deployed in environments that require SIP identity 
				<xref target="RFC4916" pageno="false" format="default" /> based peer-to-peer SDP protection.
			</t>				
		</section>		
		<section title="TLS" toc="default">
			<t>				
				This document considers two approaches how an Middlebox handles TLS protected MSRP connections.
			</t>
			<t>
				In the first approach, the Middlebox 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 Middlebox will see encrypted MSRP media packets, but is unable to inspect the cleartext 
				content.
			</t>
			<t>
				In the second approach, the Middlebox acts as a TLS B2BUA, 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. With this approach, the Middlebox can inspect and modify the MSRP message content.
			</t>
		</section>		
    </section>	
	
    <section title="Security Considerations" anchor="sec-security" toc="default">					
		<section title="Man in the middle" anchor="sec-security-mitm" 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.
			</t>
		</section>
				
		<section title="TLS" anchor="sec-security-tls" toc="default">
			<t>
				The CEMA extension supports the usage of name based authentication for TLS, also in 
				the presence of Middleboxes.
			</t>
			<t>
				NOTE: If an Middlebox acts as a TLS B2BUA, MSRP endpoints will also 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 a TLS endpoints, MSRP endpoints 
				might be given an incorrect impression that there is an end-to-end SA between the 
				MSRP endpoints.
			</t>
			<t>
				If an 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, 
				an MSRP endpoint supporting the CEMA extension SHOULD also support an authentication 
				mechanism that does not rely on peer-to-peer SDP integrity.
			</t>
			<t>
				It is RECOMMENDED that an MSRP endpoint supports one of the following authentication 
				mechanisms:
			</t>
			<t>
				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.
			</t>
			<t>
				2) TLS-PSK managed e.g. by MIKEY-TICKET based Key Management and Key
				Management Service <xref target="RFC6043" pageno="false" format="default" />.
			</t>
			<t>
				NOTE: 3GPP has specified usage of the MIKEY-TICKET based Key
				Management and Key Management Service authentication mechanism for
				the IP Multimedia Subsystem (IMS).
			</t>
			<t>
				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.
			</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 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.
			</t>
			<t>
				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.
			</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>
        <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![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: no
]]></artwork>
      </section>
    </section>
	
    <section title="Acknowledgements" anchor="sec-acks" 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 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-12
				<list style="symbols">
					<t>Extension name changed to Connection Establishment for Media Anchoring (CEMA).</t>
					<t>Middlebox defintion 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.6135"?>
    </references>
    <references title="Informative References">
		<?rfc include="reference.RFC.4916"?>
		<?rfc include="reference.RFC.6043"?>
		<?rfc include="reference.3GPP.23.228"?>
	</references>
</back>
</rfc>