idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4566]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2011) is 4695 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft S. Blau 4 Intended status: Standards Track Ericsson 5 Expires: December 18, 2011 June 16, 2011 7 Connection Establishment for Media Anchoring (CEMA) for the Message 8 Session Relay Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-13.txt 11 Abstract 13 This document defines an MSRP extension, Connection Establishment for 14 Media Anchoring (CEMA). Support of the extension is optional. MSRP 15 endpoints can implement the extension in order to allow MSRP 16 communication in networks where Middleboxes anchor the MSRP 17 connection, without the need for the Middleboxes to enable MSRP B2BUA 18 functionality in most cases. The document also defines a Session 19 Description Protocol (SDP) [RFC4566] attribute, a=msrp-cema, that can 20 be used by MSRP endpoints to indicate support of the CEMA extension. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 18, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Applicability statement . . . . . . . . . . . . . . . . . . . 5 59 4. Connection Establishment for Media Anchoring Mechanism . . . . 5 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. MSRP Offerer Procedures . . . . . . . . . . . . . . . . . 5 62 4.3. MSRP Answerer Procedures . . . . . . . . . . . . . . . . . 6 63 4.4. Usage With The Alternative Connection Model . . . . . . . 8 64 5. Middlebox assumptions . . . . . . . . . . . . . . . . . . . . 8 65 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. MSRP awareness . . . . . . . . . . . . . . . . . . . . . . 8 67 5.3. TCP connection reuse . . . . . . . . . . . . . . . . . . . 9 68 5.4. SDP integrity . . . . . . . . . . . . . . . . . . . . . . 9 69 5.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6.1. Man in the middle . . . . . . . . . . . . . . . . . . . . 9 72 6.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. IANA Registration of the SDP a=msrp-cema attribute . . . . 11 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 76 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 85 use MSRP relays [RFC4976] as a means for Network Address Translation 86 (NAT) traversal and policy enforcement. 88 However, many Session Initiation Protocol (SIP) [RFC3261] networks, 89 in which MSRP usage is emerging, also contain Middleboxes, that 90 anchor and control media, perform tasks such as NAT traversal, 91 performance monitoring, lawful intercept, address domain bridging, 92 interconnect Service Layer Agreement (SLA) policy enforcement, etc. 93 An example is the Interconnection Border Control Function (IBCF) 94 [3GPP.23.228], defined by the 3rd Generation Partnership Project 95 (3GPP). The IBCF controls a media relay that handles all types of 96 SIP session media (voice, video, MSRP, etc). 98 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot 99 be anchored when MSRP endpoints communicate with such Middleboxes, 100 unless the Middleboxes implement and enable MSRP Back-To-Back User 101 Agent (B2BUA) functionality for all calls. The reason is that 102 Middleboxes modify the address:port information in SDP c/m-line in 103 order to anchor media, and since the active MSRP UA establishes the 104 MSRP TCP connection based on the MSRP URI of the SDP a=path 105 attribute, this means that the MSRP connection will not, unless the 106 Middlebox also modifies the MSRP URI of the topmost SDP a=path 107 attribute be routed through the Middlebox, which in many scenarios 108 will prevent the MSRP connection from being established. However, if 109 the Middlebox modifies the MSRP URI of the SDP a=path attribute, then 110 the MSRP URI comparison procedure [RFC4975], which requires 111 consistency between the address information in the MSRP messages and 112 the address information carried in the MSRP URI of the SDP a=path 113 attribute, will fail. The matching will fail if Middleboxes modify 114 the address information in the MSRP URI of the SDP a=path attribute, 115 but do not enable MSRP B2BUA functionality and perform the 116 corresponding modification in the associated MSRP messages. However, 117 the enabling of MSRP B2BUA functionality requires substantially more 118 resource usage in the Middlebox, that normally result in negative 119 performance impact. 121 This specification defines an MSRP extension, Connection 122 Establishment for Media Anchoring (CEMA), that in most cases allows 123 MSRP endpoints to communicate with Middleboxes without a need for the 124 Middleboxes to enable MSRP B2BUA functionality. In such cases, 125 Middleboxes that want to anchor the MSRP connection simply modify the 126 SDP c/m-line address information (similar to what it does for non- 127 MSRP media types), and MSRP endpoints that support the CEMA extension 128 will use the SDP c/m-line address information for establishing the 129 TCP (or TLS) connection to be used for sending and receiving of MSRP 130 messages. 132 The CEMA extension is fully backward compatible. In scenarios where 133 MSRP endpoints that do not support the CEMA extension are able to 134 establish MSRP connectivity, an MSRP endpoint that supports the CEMA 135 extension behaves in the same way as an MSRP endpoint that does not 136 support it. The CEMA extension only provides an alternative 137 mechanism for negotiating and providing the address information for 138 the MSRP TCP connection. Once the MSRP TCP connection has been 139 created, an MSRP endpoint that supports the CEMA extension acts 140 according to the procedures (e.g. for creating MSRP messages, 141 performing checks when receiving MSRP messages etc) defined in RFC 142 4975 (and RFC 4976, when it is using a relay for MSRP communication). 144 2. Conventions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in BCP 14, RFC 2119 149 [RFC2119]. 151 In this specification the terminology "fingerprint based TLS 152 authentication" and "name based TLS authentication" are used to refer 153 to the two cases where: 155 1. An MSRP endpoint uses a self-signed TLS certificate and sends a 156 certificate fingerprint in SDP (fingerprint based TLS 157 authentication). 159 2. An MSRP endpoint uses a certificate from a well known certificate 160 authority and the other endpoint matches the hostname in the received 161 TLS communication SubjectAltName parameter towards the hostname 162 received in the MSRP URI in SDP (name based TLS authentication). 164 Middlebox: Within the scope of this document, Middlebox refers to a 165 network SIP device that modifies SDP media address:port information 166 in order to steer (anchor) media flows described in the SDP, 167 including TCP connections used for MSRP communication, through a 168 media proxy function controlled by the SIP device. In most cases the 169 media proxy function relays the MSRP messages without modification, 170 while in other cases it enables MSRP B2BUA functionality. Other SIP 171 related functions (e.g. related to routing, modification of SIP 172 information etc) performed by the SIP device, and whether it acts a 173 SIP B2BUA or not, is outside the scope of the definition. Section 5 174 describes additional assumptions regarding how the Middlebox handles 175 MSRP in order to support the extension defined in this document. 177 3. Applicability statement 179 This document defines an MSRP extension, Connection Establishment for 180 Media Anchoring (CEMA). Support of the extension is optional. MSRP 181 endpoints can implement the extension in order to allow MSRP 182 communication in networks where Middleboxes anchor the MSRP 183 connection, without the need for the Middleboxes to enable MSRP B2BUA 184 functionality in most cases. The document also defines a Session 185 Description Protocol (SDP) [RFC4566] attribute, a=msrp-cema, that can 186 be used by MSRP endpoints to indicate support of the CEMA extension. 188 The CEMA extension is primarily intended for MSRP endpoints that 189 operate in networks in which Middleboxes that want to anchor media 190 connections are deployed, without the need for the Middleboxes to 191 enable MSRP B2BUA functionality. An example of such network is the 192 IP Multimedia Subsystem (IMS) defined by the 3rd Generation 193 Partnership Project (3GPP). The extension is also useful for other 194 MSRP endpoints operating in other networks, but that communicate with 195 MSRP endpoints in networks with such Middleboxes, unless there is a 196 gateway between the networks that by default always enable MSRP B2BUA 197 functionality. 199 4. Connection Establishment for Media Anchoring Mechanism 201 4.1. General 203 This section defines how an MSRP endpoint that supports the CEMA 204 extension generates SDP offers and answers for MSRP, and what SDP 205 information elements the MSRP endpoint uses when creating the TCP 206 connection for the MSRP messages. 208 4.2. MSRP Offerer Procedures 210 When an MSRP endpoint sends an SDP offer for MSRP, it generates the 211 SDP offer according to the procedures in RFC 4975 (and RFC 4976, if 212 it is using a relay for MSRP communication), with the following 213 additions and modifications: 215 1) The MSRP endpoint MUST include an SDP a=msrp-cema attribute in the 216 MSRP media description of the SDP offer. 218 2) If the MSRP endpoint is not using a relay for MSRP communication, 219 it MUST include an SDP a=setup attribute in the MSRP media 220 description of the SDP offer, according to the procedures in RFC 221 [RFC6135]. 223 3) If the MSRP endpoint is using a relay for MSRP communication, it 224 MUST include the address information on the relay (the MSRP URI of 225 the topmost SDP a=path attribute), rather than the address 226 information of itself, in the SDP c/m-line associated with the MSRP 227 media description. In addition, it MUST include an SDP a=setup: 228 actpass attribute in the MSRP media description of the SDP offer. 230 When the MSRP endpoint receives the first SDP answer to the SDP offer 231 above, and the SDP answer indicates that the offered MSRP media has 232 been accepted by the remote MSRP endpoint (i.e. the port number of 233 the MSRP media description is not set to zero), if the MSRP media 234 description of the SDP answer does not contain an SDP a=msrp-cema 235 attribute, the MSRP endpoint MUST check whether any of the following 236 criteria is fulfilled: 238 1) The SDP c/m-line address information associated with the MSRP 239 media description does not match the information in the MSRP URI of 240 the topmost SDP a=path attribute, and the MSRP media description 241 contains an SDP a=setup:active attribute (indicating that the remote 242 MSRP endpoint is "active"). 244 2) The MSRP media description contains multiple SDP a=path attributes 245 (indicating that MSRP relays are used). 247 If any, or both, of the criteria above is fulfilled, the MSRP 248 endpoint MUST fallback to RFC 4975 behavior, by sending a new SDP 249 offer according to the procedures in RFC 4975 and RFC 4976. The new 250 offer MUST NOT contain an SDP a=msrp-cema attribute. 252 NOTE: In the absence of the SDP a=msrp-cema attribute in the new 253 offer, the Middlebox will in all cases have to, in order to be able 254 to anchor MSRP media, enable MSRP B2BUA functionality. 256 NOTE: The MSRP endpoint can send the new offer within the existing 257 early dialog [RFC3261], or it can terminate the early dialog and 258 establish a new dialog by sending the new offer in a new initial 259 INVITE request. 261 In all other cases, where the MSRP endpoint becomes "active", it MUST 262 use the SDP c/m-line for establishing the MSRP TCP connection. If 263 the MSRP endpoint becomes "passive", it will wait for the remote MSRP 264 endpoint to establish the TCP connection, according to the procedures 265 in RFC 4975. 267 4.3. MSRP Answerer Procedures 269 When an MSRP endpoint receives an SDP offer for MSRP, it MUST check 270 the following criteria: 272 1) Both MSRP endpoints are using relays for MSRP communication. 274 NOTE: If the MSRP media description of the SDP offer contains 275 contains multiple SDP a=path attributes, it can be determined that 276 the remote MSRP endpoint is using a relay for MSRP communication. 278 2) The remote MSRP endpoint uses a relay for MSRP communciation, and 279 will become "active" (either by default, or if the MSRP media 280 description of the SDP offer contains an SDP a=setup:active 281 attribute). 283 NOTE: This case should not occur if the remote MSRP endpoint supports 284 the CEMA extension, as the remote MSRP endpoint would include an SDP 285 a=setup:actpass attribute in the SDP offer, as described in section 286 4.2. 288 3) The MSRP endpoint uses a relay for MSRP communication, and is not 289 able to become "passive" (the MSRP media description of the offer 290 contains an SDP a=setup:passive attribute). 292 NOTE: This case should never occur, as an MSRP entity is not allowed 293 to include an SDP a=setup:passive attribute in an SDP offer, as 294 described in RFC 6135. 296 4) The MSRP media description of the SDP offer does not contain an 297 SDP a=msrp-cema attribute, the SDP c/m-line address information 298 associated with the MSRP media description does not match the 299 information in the MSRP URI of the topmost SDP a=path attribute, and 300 the remote MSRP endpoint will become "active" (either by default, or 301 if the MSRP media description of the SDP offer contains an SDP 302 a=setup:active attribute). 304 If any, or all, of the criteria above is fulfilled, the MSRP endpoint 305 MUST fallback to RFC 4975 behavior, and generate the associated SDP 306 answer according to the procedures in RFC 4975 and RFC 4976. The 307 MSRP endpoint MUST NOT insert an SDP a=msrp-cema attribute in the 308 MSRP media description of the SDP answer. 310 In all other cases, the MSRP endpoint generates the associated SDP 311 answer according to the procedures in RFC 4975 and RFC 4976, with the 312 following additions and modifications: 314 1) The MSRP endpoint MUST include an SDP a=msrp-cema attribute in the 315 MSRP media description of the SDP answer. 317 2) If the MSRP endpoint is not using a relay for MSRP communication, 318 it MUST include an SDP a=setup attribute in the MSRP media 319 description of the answer, according to the procedures in RFC 6135. 321 3) If the MSRP endpoint is using a relay for MSRP communication, it 322 MUST include the address information on the relay (the MSRP URI of 323 the topmost SDP a=path attribute), rather than the address 324 information of itself, in the SDP c/m-line associated with the MSRP 325 media description. In addition, it MUST include an SDP a=setup: 326 passive attribute in the MSRP media description of the SDP answer. 328 If the MSRP endpoint included an SDP a=msrp-cema attribute in the 329 MSRP media description of the SDP answer, and if the MSRP endpoint 330 becomes "active", it MUST use the received SDP c/m-line for 331 establishing the MSRP TCP connection. If the MSRP endpoint becomes 332 "passive", it will wait for the remote MSRP endpoint to establish the 333 TCP connection, according to the procedures in RFC 4975. 335 4.4. Usage With The Alternative Connection Model 337 An MSRP endpoint that supports the CEMA extension MUST in addition 338 also support the mechanism defined in RFC 6135, as it extends the 339 number of scenarios where the CEMA extension can be used, and 340 Middleboxes do not need to enable MSRP B2BUA functionality. An 341 example is where a MSRP endpoint is using a relay for MSRP 342 communication, and it needs to be "passive" in order to use the CEMA 343 extension (instead of doing a fallback to RFC 4975 behavior. 345 5. Middlebox assumptions 347 5.1. General 349 This document does not specify explicit Middlebox behavior, 350 eventhough some of the procedures will be enabled by Middleboxes. 351 However, as the main reason behind the CEMA extension is to allow 352 MSRP endpoints to communicate in networks where Middleboxes that want 353 to anchor media are present, this document makes certain assumptions 354 regarding to how such Middleboxes behave. 356 5.2. MSRP awareness 358 This document assumes that an Middlebox, in order to support 359 interoperability between UAs that support the CEMA extension and UAs 360 that do not support the extension, is MSRP aware, meaning that it 361 implements MSRP B2BUA functionality, and that it enables that 362 functionality in cases where support of the CEMA extension is not 363 indicated. In cases where support of the CEMA extension is indicated 364 by at least one MSRP endpoint, the Middlebox can simply modifies the 365 SDP c/m-line address information for the MSRP connection. However, 366 MSRP communication will work if the Middlebox enables MSRP B2BUA 367 functionality also in such cases. 369 5.3. TCP connection reuse 371 When the CEMA extension is used, in cases where Middleboxes do not 372 need to enable MSRP B2BUA functionality, the Middleboxes are not 373 required to parse and modify the MSRP payload. An Middlebox that 374 does not parse the MSRP payload might not enable re-usage of TCP 375 connections for multiple MSRP sessions. Instead, in order to 376 associate an MSRP message with a specific session, the Middlebox 377 often assigns a unique local address:port combination for each MSRP 378 session. 380 5.4. SDP integrity 382 This document assumes that Middleboxes are able to modify the SDP 383 address information associated with the MSRP media, and therefore can 384 not be deployed in environments that require SIP identity [RFC4916] 385 based peer-to-peer SDP protection. 387 5.5. TLS 389 This document considers two approaches how an Middlebox handles TLS 390 protected MSRP connections. 392 In the first approach, the Middlebox relays the MSRP media packets at 393 the transport layer. The TLS handshake and resulting security 394 association (SA) are established peer-to-peer between the MSRP 395 endpoints. The Middlebox will see encrypted MSRP media packets, but 396 is unable to inspect the cleartext content. 398 In the second approach, the Middlebox acts as a TLS B2BUA, meaning 399 that separate SAs are established between the Middlebox and each MSRP 400 endpoint. The Middlebox decrypts MSRP media packets received from 401 one MSRP endpoint, and then re-encrypts them before sending them 402 toward the other MSRP endpoint. With this approach, the Middlebox 403 can inspect and modify the MSRP message content. 405 6. Security Considerations 407 6.1. Man in the middle 409 In some cases, where MSRP B2BUA functionality does not need to be 410 enabled, the CEMA extension makes it easier for a man in the middle 411 (MiTM) to transparently insert itself in the communication between 412 MSRP endpoints in order to monitor or record unprotected MSRP 413 communication. It does not however make it easier for a MiTM to 414 monitor TLS protected MSRP, or in any significant way modify TLS 415 protected MSRP content or even find out that the packets contain MSRP 416 messages, since that would require the MiTM to implement MSRP B2BUA 417 functionality, no matter if UAs support the CEMA extension or not. 418 It would thus require the MiTM to terminate the TCP/TLS/MSRP 419 connection in both directions. 421 6.2. TLS 423 The CEMA extension supports the usage of name based authentication 424 for TLS, also in the presence of Middleboxes. 426 NOTE: If an Middlebox acts as a TLS B2BUA, MSRP endpoints will also 427 be able to use fingerprint based authentication for TLS, no matter if 428 they support the CEMA extension or not. In such cases, as the 429 Middlebox acts as a TLS endpoints, MSRP endpoints might be given an 430 incorrect impression that there is an end-to-end SA between the MSRP 431 endpoints. 433 If an Middlebox does not act as a TLS B2BUA, fingerprint based 434 authentication will not work, as the "SIP Identity" based integrity 435 protection of SDP will break. Therefore, in addition to the 436 authentication mechanisms defined in RFC 4975, an MSRP endpoint 437 supporting the CEMA extension SHOULD also support an authentication 438 mechanism that does not rely on peer-to-peer SDP integrity. 440 It is RECOMMENDED that an MSRP endpoint supports one of the following 441 authentication mechanisms: 443 1) TLS certificates together with support of interacting with a 444 Certificate Management Service [ref to draft-ietf-sip-certs], to 445 which it publishes the public version of its own self-signed 446 certificate and from which it fetches on need the public certificates 447 of other endpoints. 449 2) TLS-PSK managed e.g. by MIKEY-TICKET based Key Management and Key 450 Management Service [RFC6043]. 452 NOTE: 3GPP has specified usage of the MIKEY-TICKET based Key 453 Management and Key Management Service authentication mechanism for 454 the IP Multimedia Subsystem (IMS). 456 When an MSRP endpoint generates an SDP offer for MSRPS it MUST, in 457 addition to the SDP attributes associated with the TLS authentication 458 mechanisms described in RFC 4975, it MUST include any information 459 elements associated with the other authentication mechanisms that it 460 supports. 462 Unless the MSRP endpoints are able to use name based authentication, 463 and they support a common authentication mechanism, they MUST use 464 that mechanism. If the MSRP endpoints do not support such common 465 authentication mechanism, they MUST try fingerprint based 466 authentication, which will succeed if there are no Middleboxes 467 present. If that also fails, the MSRP endpoints MUST either: 469 1) Consider the TLS authentication as failed, in accordance with RFC 470 4975; or 472 2) If the SIP signalling between the MSRP endpoints is protected 473 through e.g. SIPS, use fingerprint based authentication without 474 requiring peer-to-peer SDP integrity, and thus trust the network 475 endpoints in the signaling path for SDP integrity. 477 NOTE: As defined in RFC 4975, if TLS authentication fails, the user 478 need to be able to decide whether to try to anyway establish an MSRP 479 connection. 481 7. IANA Considerations 483 7.1. IANA Registration of the SDP a=msrp-cema attribute 485 This section registers a new SDP attribute, a=msrp-cema. The 486 required information for this registration, as specified in RFC 4566, 487 is: 489 Contact name: Christer Holmberg 491 Contact e-mail: christer.holmberg@ericsson.com 493 Attribute name: a=msrp-cema 495 Type of attribute: media level 497 Purpose: This attribute is used to indicate support of 498 the MSRP Connection Establishment for Media 499 Anchoring (CEMA) extension defined in 500 RFC XXXX. When present in an MSRP media 501 description of an SDP body, it indicates 502 that the sending UA supports the CEMA 503 mechanism. 505 Values: The attribute does not carry a value 507 Charset dependency: no 509 8. Acknowledgements 511 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 512 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 513 Ted Hardie, Richard L Barnes, Inaki Baz Castillo, Saul Ibarra 514 Corretge and Adrian Georgescu for their guidance and input in order 515 to produce this document. 517 9. Change Log 519 [RFC EDITOR NOTE: Please remove this section when publishing] 521 Changes from draft-ietf-simple-msrp-sessmatch-12 522 o Extension name changed to Connection Establishment for Media 523 Anchoring (CEMA). 524 o Middlebox defintion added. 525 o ALG terminology replaced with Middlebox. 526 o SDP attribute name changed to a=msrp-cema. 527 o Applicability Statement section expanded. 528 o Re-structuring of MSRP Answerer section. 529 o Changes based on comments from Saul Ibarra Corretge (1406111). 531 Changes from draft-ietf-simple-msrp-sessmatch-11 532 o Modification of the sessmatch mechanism. 533 o - Extension name changed to Alternative Connection Establishment 534 (ACE) 535 o - Session matching procedure no longer updated. 536 o - SDP c/m-line used for MSRP TCP connection. 537 o - sessmatch option-tag removed. 538 o - a=msrp-ace attribute defined. 539 o - Support of RFC 6135 mandatory. 541 Changes from draft-ietf-simple-msrp-sessmatch-10 542 o Sessmatch option-tag added, based on WG discussions and concensus. 544 Changes from draft-ietf-simple-msrp-sessmatch-08 545 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 547 Changes from draft-ietf-simple-msrp-sessmatch-07 548 o Sessmatch defined as an MSRP extension, rather than MSRP update 549 o Additional security considerations text added 551 10. References 552 10.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 558 A., Peterson, J., Sparks, R., Handley, M., and E. 559 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 560 June 2002. 562 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 563 Description Protocol", RFC 4566, July 2006. 565 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 566 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 568 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 569 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 570 September 2007. 572 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 573 for the Message Session Relay Protocol (MSRP)", RFC 6135, 574 February 2011. 576 10.2. Informative References 578 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 579 Protocol (SIP)", RFC 4916, June 2007. 581 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 582 Modes of Key Distribution in Multimedia Internet KEYing 583 (MIKEY)", RFC 6043, March 2011. 585 [3GPP.23.228] 586 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 587 TS 23.228 10.5.0, June 2011. 589 Authors' Addresses 591 Christer Holmberg 592 Ericsson 593 Hirsalantie 11 594 Jorvas 02420 595 Finland 597 Email: christer.holmberg@ericsson.com 598 Staffan Blau 599 Ericsson 600 Stockholm 12637 601 Sweden 603 Email: staffan.blau@ericsson.com