idnits 2.17.1 draft-ietf-simple-msrp-acm-09.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 : ---------------------------------------------------------------------------- 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 (June 1, 2010) is 5077 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) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: December 3, 2010 Ericsson AB 6 June 1, 2010 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-ietf-simple-msrp-acm-09.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-oriented 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 endpoint initiates 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 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 3, 2010. 39 Copyright Notice 41 Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 59 4. COMEDIA for MSRP . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. a=setup . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2.2. Attribute usage . . . . . . . . . . . . . . . . . . . . 4 64 4.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.4. a=connection . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.5. MSRP relay connection . . . . . . . . . . . . . . . . . . . 6 67 5. Interoperability with connection model defined in RFC 4975 . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 71 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The Message Session Relay Protocol (MSRP) core specification 80 [RFC4975] defines that the MSRP UA which sends the SDP offer is 81 "active", and it is responsible for creating the MSRP transport 82 connection towards the remote UA if a new connection is required. 83 The core specification also allows, but does not define, alternate 84 mechanisms for MSRP UAs to create MSRP transport connections. 86 [RFC4145] defines a connection-oriended media mechanism, COMEDIA, 87 that endpoints can use to negotiate the endpoint which initiates the 88 creation of media transport connection. 90 COMEDIA is especially useful when an endpoint is located behind a 91 NAT. The endpoint can use the mechanism to indicate that it will 92 create the media transport connection, in order for the media to 93 traverse the NAT without the usage of relays, without being required 94 to support more complex mechanims (e.g. TCP Candidates with 95 Interactive Connectivity Establishment (ICE) 96 [I-D.ietf-mmusic-ice-tcp]). In addition, COMEDIA allows the usage of 97 identical procedures in establishing TCP connections for different 98 types of media. 100 An example is the Open Mobile Alliance (OMA) defined "Instant Message 101 using SIMPLE" [OMA-TS-SIMPLE_IM-V1_0-20090901-D], where one MSRP UA 102 of every MSRP transport connection represents a media server, which 103 is always located in the carrier network. The media server has a 104 global IP address and handles application specific policy control as 105 well as NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA 106 for NAT traversal, and all OMA IM MSRP clients support COMEDIA. 108 This document defines how an MSRP UA uses COMEDIA in order to 109 negotiate which UA will create the MSRP transport TCP connection 110 towards the other UA. The document also defines how an MSRP UA which 111 uses COMEDIA can establish an MSRP transport connection with a remote 112 UA that does not support COMEDIA. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 3. Applicability statement 122 Support of this specification is optional for MSRP user agents in 123 general. User Agents that are likely to be deployed in networks with 124 NATs SHOULD support this specification. It will improve the odds of 125 being able to make TCP connections successfully traverse NATs, since 126 User Agents behind NATs can be requested to initiate the 127 establishment of the TCP connections. 129 4. COMEDIA for MSRP 131 4.1. General 133 This section defines how an MSRP UA that supports this specification 134 uses the COMEDIA SDP attributes defined in [RFC4145]. 136 4.2. a=setup 138 4.2.1. General 140 An MSRP UA uses the SDP a=setup attribute [RFC4145], in order to 141 negotiate which endpoint will create the MSRP transport connection 142 towards the other UA. 144 An MSRP UA MUST always include an explicit a=setup attribute in its 145 SDP offers and answers, since it might be useful for the other 146 endpoint, or for entities in the network, to know whether the UA 147 supports COMEDIA or not. 149 An MSRP UA must support the a=setup "active", "actpass" and "passive" 150 attribute values. An MSRP UA MUST NOT send the "holdconn" attribute, 151 and MUST ignore it if received. 153 4.2.2. Attribute usage 155 When the a=setup attribute value is "actpass" or "passive", the IP 156 address and port values in the MSRP URI of the SDP a=path attribute 157 MUST contain the actual address and port values on which the UA can 158 receive a TCP Open request for the MSRP transport connection. 160 In accordance with [RFC4145], if the a=setup attribute value is 161 "active", the port number value should be 9. 163 If an MSRP UA can provide a global IP address that the other endpoint 164 can use as destination for a TCP Open request, the UA MUST use the 165 a=setup "actpass" attribute value in SDP offers. This is in order to 166 allow the remote UA to send an SDP answer with an a=setup "active" 167 attribute value if the UA is located behind NAT, and in order to be 168 compatible with UAs that do not support COMEDIA and thus always will 169 act as passive endpoints. If an MSRP UA cannot provide the actual 170 transport address, the UA MUST use the a=setup "active" attribute 171 value. 173 The UA MUST NOT use the a=setup "passive" attribute value in an SDP 174 offer. 176 The MSRP UA can determine that it provides a global IP address in the 177 following scenarios: 179 - the UA can determine that it is not located behind a NAT; 181 - the UA relays its MSRP transport connections via a relay (e.g. 182 MSRP relay or TURN server); or 184 - the UA has used Session Traversal Utilities for NAT (STUN) 185 [RFC5389] signaling to retrieve NAT address and port through the 186 local port to be used for the eventual transport connection, while 187 also having determined that the NAT is not address restricted. 189 Some UAs can determine whether the SIP [RFC3261] signaling has 190 traversed a NAT by inspecting the SIP Via header field in the 200 191 (OK) response to the initial SIP REGISTER request, and comparing the 192 IP addresses in the Via sent-by and the received header field 193 parameters. If the IP addresses are not the same then the UA can 194 determine that there is a NAT in the path. Even though the media 195 transport might not traverse the NAT, it is safe to assume that it 196 will, and set the a=setup attribute accordingly. This comparing 197 mechanism does not work in all scenarios, though. For example, if 198 SIP a requests crosses a SIP proxy before crossing a NAT, the UA will 199 not be able to detect the NAT by comparing the IP addresses. 201 If an SDP offer includes an a=setup "actpass" attribute value, the 202 SDP answerer MAY include an a=setup "active" attribute value in the 203 SDP answer, but SHOULD include a=setup "passive" attribute value if 204 it knows that it is not located behind a NAT. 206 Once the active UA has established the MSRP transport connection, the 207 UA must immediately send an MSRP SEND request, as defined in 208 [RFC4975]. 210 NOTE: According to [RFC4975] the initiating UA is always active, but 211 when COMEDIA is used the a=setup attribute is used to negotiate which 212 UA becomes active. 214 4.3. TLS 216 If an MSRP UA conformant to this document uses TLS, it MUST use the 217 TLS mechanisms defined in [RFC4975] and [RFC4976]. 219 According to [RFC4975], the connection can be established with or 220 without TLS mutual authentication. In case mutual authentication is 221 not used, the listening device waits until it receives a request on 222 the connection, at which time it infers the identity of the 223 connecting device from the associated session description. From TLS 224 authentication point of view it is thus irrelevant whether an 225 endpoint takes the active or passive role. 227 If an MSRP UA uses a self-signed TLS certificate to authenticate 228 itself to MSRP peers it also includes its certificate fingerprint in 229 the SDP. 231 Note that fingerprints can only be exchanged in peer-to-peer 232 communication, as MSRP relays [RFC4976] will not receive the SDP 233 payloads containing the fingerprint attributes. 235 4.4. a=connection 237 MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] 238 defines connection reuse procedures for MSRP, and this document does 239 not modify those procedures. 241 If an MSRP UA receives an a=connection attribute, the UA MUST ignore 242 it. 244 4.5. MSRP relay connection 246 If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST 247 always initiate a transport connection towards the relay, no matter 248 what value the client has provided in the a=setup attribute. 250 NOTE: Even if an MSRP UA initiates the TCP connection towards its 251 relay, the UA will only send a SEND request if the UA is active, 252 based on the COMEDIA negotiation. 254 5. Interoperability with connection model defined in RFC 4975 256 An MSRP UA conformant to this document can interoperate with a UA 257 that follows the connection model defined in [RFC4975]. However, if 258 an MSRP UA conformant to this document is located behind NAT, and 259 does not proxy its MSRP communication via an MSRP relay, and the UA 260 receives an SDP offer from a remote UA that follows the connection 261 model defined in [RFC4975], NAT traversal can only be achieved if the 262 MSRP UA supports ICE [I.D.ietf-mmusic-ice-tcp] and the network 263 provides TURN servers, or if the network supports SBC assisted NAT 264 traversal for TCP. 266 6. Security Considerations 268 According to the connection model defined in [RFC4975], the MSRP UA 269 that sends the SDP offer becomes the active party, and it is 270 responsible for creating the MSRP transport connection towards the 271 remote UA if a new connection is required. 273 When COMEDIA is used, either the sender or the receiver of the SDP 274 offer can become the active party. [RFC4975] requires that the 275 active party immediately issues an MSRP SEND request once the 276 connection has been established. This allows the passive party to 277 bind the inbound TCP connection to the message session identified by 278 the session id part of its MSRP URI. The use of COMEDIA does not 279 change this requirement, but the sender of the SDP offer is no longer 280 assumed to always become the active party. 282 The active party also takes the role as TLS client, if TLS is used to 283 protect the MSRP messages. However, there are no procedures in 284 [RFC4975] that would break in case the receiver of the SDP offer 285 takes the role as TLS client, and the level of security provided by 286 TLS is not affected. 288 7. IANA Considerations 290 This document has no actions for IANA. 292 8. Acknowledgements 294 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 295 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 296 Schubert for their guidance and input in order to produce this 297 document. 299 9. Change Log 301 [RFC EDITOR NOTE: Please remove this section when publishing] 303 Changes from draft-ietf-simple-msrp-acm-08 304 o Changes based on comments from Gonzalo Camrillo. 306 Changes from draft-ietf-simple-msrp-acm-07 307 o WGLC editorial changes. 309 Changes from draft-ietf-simple-msrp-acm-06 310 o WGLC changes. 312 Changes from draft-ietf-simple-msrp-acm-05 313 o TLS section modified. 315 Changes from draft-ietf-simple-msrp-acm-04 316 o TLS section modified. 317 o Security considerations section modified. 319 Changes from draft-ietf-simple-msrp-acm-03 320 o Changes based on WGLC comments from Adam Roach and Ben Campbell. 321 o New section added related to interoperability with connection 322 model defined in RFC 4975. 323 o Text related to a=setup "holdconn" attribute value removed. 324 o NAT keepalive section removed. 325 o Usage of COMEDIA-TLS removed. 327 Changes from draft-ietf-simple-mscp-acm-02 328 o Changes based on WGLC comments from Salvatore Loreto and Shida 329 Schubert. 331 Changes from draft-ietf-simple-msrp-acm-01 332 o Procedures for using SDP c/m for routing of MSRP messages removed. 333 o Procedures related to modification of MSRP address information by 334 intermediates moved to separate document. 335 o Solution to open issue on usage of the SDP a=connection 336 implemented. 338 10. References 340 10.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 346 the Session Description Protocol (SDP)", RFC 4145, 347 September 2005. 349 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 350 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 352 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 353 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 354 September 2007. 356 10.2. Informative References 358 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 359 A., Peterson, J., Sparks, R., Handley, M., and E. 360 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 361 June 2002. 363 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 364 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 365 October 2008. 367 [I-D.ietf-mmusic-ice-tcp] 368 Perreault, S. and J. Rosenberg, "TCP Candidates with 369 Interactive Connectivity Establishment (ICE)", 370 draft-ietf-mmusic-ice-tcp-08 (work in progress), 371 October 2009. 373 Authors' Addresses 375 Christer Holmberg 376 Ericsson 377 Hirsalantie 11 378 Jorvas 02420 379 Finland 381 Email: christer.holmberg@ericsson.com 383 Staffan Blau 384 Ericsson AB 385 P.O Box 407 386 Sweden 388 Email: staffan.blau@ericsson.com