idnits 2.17.1 draft-ietf-simple-msrp-acm-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2010) is 5159 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 informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Blau 5 Expires: September 6, 2010 Ericsson AB 6 March 5, 2010 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-ietf-simple-msrp-acm-06.txt 12 Abstract 14 This document defines an alternative connection model for Message 15 Session Relay Protocol (MSRP) User Agents (UAs), which uses the 16 connection-oriended media (COMEDIA) mechanism in order to create the 17 MSRP transport connection. The model allows MSRP UAs behind Network 18 Address Translators (NATs) to negotiate which UA will initiate the 19 establishment of the TCP connection, in order for MSRP messages to 20 traverse the NAT. 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 6, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 65 4. COMEDIA for MSRP . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.2. a=setup . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.4. a=connection . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.5. MSRP relay connection . . . . . . . . . . . . . . . . . . . 6 71 5. Interoperability with connection model defined in RFC 4975 . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 The Message Session Relay Protocol (MSRP) core specification 84 [RFC4975] defines that the MSRP UA which sends the SDP offer is 85 "active", and it is responsible for creating the MSRP transport 86 connection towards the remote UA if a new connection is required. 87 The core specifcation also allows, but does not define, alternate 88 mechanisms for MSRP UAs to create MSRP transport connections. 90 [RFC4145] defines a connection-oriended media mechanism, COMEDIA, 91 that endpoints can use to negotiate the endpoint which initiates the 92 creation of media transport connection. 94 COMEDIA is especially useful when an endpoint is located behind a 95 NAT. The endpoint can use the mechanism to indicate that it will 96 create the media transport connection, in order for the media to 97 traverse the NAT without the usage of relays. 99 An example is the Open Mobile Alliance (OMA) defined "Instant Message 100 using SIMPLE" [OMA-TS-SIMPLE_IM-V1_0-20090901-D], where one MSRP UA 101 of every MSRP transport connection represents a media server, which 102 is always located in the carrier network. The media server has a 103 global IP address and handles application specific policy control as 104 well as NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA 105 for NAT traversal, and all OMA IM MSRP clients support COMEDIA. 107 This document defines how an MSRP UA uses COMEDIA in order to 108 negotiate which UA will create the MSRP transport TCP connection 109 towards the other UA. The document also defines how an MSRP UA which 110 uses COMEDIA can establish an MSRP transport connection with a remote 111 UA that does not support COMEDIA. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 3. Applicability statement 121 Support of this specification is optional for MSRP user agents in 122 general. User Agents that are likely to be deployed in networks 123 where User Agents need to establish the TCP connections in order to 124 traverse NATs SHOULD support this specification in order to improve 125 the odds of being able to communicate across NATs. 127 4. COMEDIA for MSRP 129 4.1. General 131 This section defines how an MSRP UA uses the COMEDIA SDP attributes 132 defined in [RFC4145]. 134 4.2. a=setup 136 An MSRP UA MUST support the SDP a=setup attribute [RFC4145], in order 137 to negotiate which endpoint will create the MSRP transport connection 138 towards the other UA. 140 The a=setup attribute is particularly useful when one MSRP UA 141 represents a network media server, or any other entity that is not 142 located behind a NAT. The a=setup attribute allows the media server 143 to ensure that MSRP UAs create the MSRP transport connections towards 144 the server, so that NATs at user's premises will not interfere with 145 the connection creation. 147 An MSRP UA MUST always include an explicit a=setup attribute in its 148 SDP offers and answers, since it is sometimes useful for the other 149 endpoint, or for entities in the network, to know whether the UA 150 supports COMEDIA or not. 152 An MSRP UA MUST support the a=setup "active", "actpass" and "passive" 153 attribute values. 155 When the a=setup attribute value is "actpass" or "passive", the IP 156 address:port value in the MSRP URI of the SDP a=path attribute MUST 157 contain the actual address:port on which the UA can receive a TCP 158 Open request for the MSRP transport connection. 160 If the a=setup attribute value is "active", the port number value 161 MUST either be the actual port number that the MSRP UA will use for 162 the TCP endpoint, or the port value 9. 164 If an MSRP UA can provide a global IP address that the other endpoint 165 can use as destination for a TCP Open request, the UA MUST use the 166 a=setup "actpass" attribute value in SDP offers. This is in order to 167 allow the remote UA to send an SDP answer with an a=setup "active" 168 attribute value if the UA is located behind NAT, and in order to be 169 compatible with MSRP UAs that do not support COMEDIA and thus always 170 will act as passive endpoints. If an MSRP UA cannot provide the 171 actual transport address, the UA MUST use the a=setup "active" 172 attribute value. 174 The UA MUST NOT use the a=setup "passive" attribute value in an SDP 175 offer. 177 The MSRP UA can determine that it provides a global IP address in the 178 following scenarios: 180 - the UA can determine that it is not located behind a NAT; 182 - the UA relays its MSRP transport connections via a relay (e.g. 183 MSRP relay or TURN server); or 185 - the UA has used Simple Traversal of UDP Through NATs (STUN) 186 [RFC5389] signalling to retrieve NAT address:port through the local 187 port to be used for the the eventual transport connection, while also 188 having determined that the NAT is not address restricted. 190 Some UAs can determinte whether the SIP [RFC3261] signaling has 191 traversed a NAT by inspecting the SIP Via header field in the 200 192 (OK) response to the initial SIP REGISTER request, and comparing the 193 IP addresses in the Via sent-by and the received header field 194 parameters. If the IP addresses are not the same then the UA can 195 determine that there is a NAT in the path. Even though the media 196 transport might not traverse the NAT, it is safe to assume that it 197 will, and set the a=setup attribute accordingly. This comparing 198 mechanism does not work in all scenarios, though. For example, if 199 the NAT contains a SIP proxy, the UA will not be able to detect the 200 NAT by comparing the IP addresses." 202 NOTE: If the NAT contains a SIP proxy, the UA will not be able to 203 detect the NAT by comparing the IP addresses. 205 If an SDP offer includes an a=setup "actpass" attribute value, the 206 SDP answer MAY include an a=setup "active" attribute value, but 207 SHOULD include a=setup "passive" attribute value if the SDP answerer 208 knows that it is not located behind a NAT. 210 Once the active UA has established the MSRP transport connection, the 211 UA MUST immediately send an MSRP SEND request, as defined in 212 [RFC4975]. 214 NOTE: According to [RFC4975] the initiating UA is always active, but 215 when COMEDIA is used the a=setup attribute is used to negotiate which 216 UA becomes active. 218 4.3. TLS 220 If an MSRP UA conformant to this document uses TLS, it MUST use the 221 TLS mechanisms defined in [RFC4975] and [RFC4976]. 223 According to [RFC4975], the connection can be established with or 224 without TLS mutual authentication. In case mutual authentication is 225 not used, the listening device waits until it receives a request on 226 the connection, at which time it infers the identity of the 227 connecting device from the associated session description. From TLS 228 authentication point of view it is thus irrelevant whether an 229 endpoint takes the active or passive role. 231 In accordance with [RFC4975], if an MSRP UA has a TLS certificate, it 232 always sends the certificate to the other endpoint during the TLS 233 establishment. If an MSRP UA uses a self-signed TLS certificate to 234 authenticate itself to MSRP peers it also includes its certificate 235 fingerprint in the SDP. 237 Note that fingerprints can only be exchanged in peer-to-peer 238 communication, as MSRP relays [RFC4976] will not receive the SDP 239 payloads containing the fingerprint attributes. 241 4.4. a=connection 243 MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] 244 defines connection reuse procedures for MSRP, and this document does 245 not modify those procedures. 247 If an MSRP UA receives an a=connection attribute, the UA MUST ignore 248 it. 250 4.5. MSRP relay connection 252 If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST 253 always initiate a transport connection towards the relay, no matter 254 what value the client has provided in the a=setup attribute. 256 NOTE: Even if an MSRP UA initiates the TCP connection towards its 257 relay, the UA will only send a SEND request if the UA is active, 258 based on the COMEDIA negotiation. 260 5. Interoperability with connection model defined in RFC 4975 262 An MSRP UA conformant to this document can interoperate with a UA 263 that follows the connection model defined in [RFC4975]. However, if 264 an MSRP UA conformant to this document is located behind NAT, and 265 does not proxy its MSRP communication via an MSRP relay, and the UA 266 receives an SDP offer from a remote UA that follows the connection 267 model defined in [RFC4975], NAT traversal can only be achieved if the 268 MSRP UA supports ICE [I.D.ietf-mmusic-ice-tcp] and the network 269 provides TURN servers, or if the network supports SBC assisted NAT 270 traversal for TCP. 272 6. Security Considerations 274 According to the connection model defined in [RFC4975], the MSRP UA 275 that sends the SDP offer becomes the active party, and it is 276 responsible for creating the MSRP transport connection towards the 277 remote UA if a new connection is required. 279 When COMEDIA is used, either the sender or the receiver of the SDP 280 offer can become the active party. [RFC4975] requires that the 281 active party immediately issues an MSRP SEND request once the 282 connection has been established. This allows the passive party to 283 bind the inbound TCP connection to the message session identified by 284 the session id part of its MSRP URI. The use of COMEDIA does not 285 change this requirement, but the sender of the SDP offer is no longer 286 assumed to always become the active party. 288 The active party also takes the role as TLS client, if TLS is used to 289 protect the MSRP messages. However, there are no procedures in 290 [RFC4975] that would break in case the receiver of the SDP offer 291 takes the role as TLS client, and the level of security provided by 292 TLS is not affected. 294 7. IANA Considerations 296 This document has no actions for IANA. 298 8. Acknowledgements 300 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 301 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 302 Schubert for their guidance and input in order to produce this 303 document. 305 9. Change Log 307 [RFC EDITOR NOTE: Please remove this section when publishing] 309 Changes from draft-ietf-simple-msrp-acm-05 310 o TLS section modified. 312 Changes from draft-ietf-simple-msrp-acm-04 313 o TLS section modified. 314 o Security considerations section modified. 316 Changes from draft-ietf-simple-msrp-acm-03 317 o Changes based on WGLC comments from Adam Roach and Ben Campbell. 318 o New section added related to interoperability with connection 319 model defined in RFC 4975. 320 o Text related to a=setup "holdconn" attribute value removed. 321 o NAT keepalive section removed. 322 o Usage of COMEDIA-TLS removed. 324 Changes from draft-ietf-simple-mscp-acm-02 325 o Changes based on WGLC comments from Salvatore Loreto and Shida 326 Schubert. 328 Changes from draft-ietf-simple-msrp-acm-01 329 o Procedures for using SDP c/m for routing of MSRP messages removed. 330 o Procedures related to modification of MSRP address information by 331 intermediates moved to separate document. 332 o Solution to open issue on usage of the SDP a=connection 333 implemented. 335 10. References 337 10.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 343 the Session Description Protocol (SDP)", RFC 4145, 344 September 2005. 346 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 347 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 349 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 350 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 351 September 2007. 353 10.2. Informative References 355 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 356 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 357 October 2008. 359 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 360 A., Peterson, J., Sparks, R., Handley, M., and E. 361 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 362 June 2002. 364 Authors' Addresses 366 Christer Holmberg 367 Ericsson 368 Hirsalantie 11 369 Jorvas 02420 370 Finland 372 Email: christer.holmberg@ericsson.com 374 Staffan Blau 375 Ericsson AB 376 P.O Box 407 377 Sweden 379 Email: staffan.blau@ericsson.com