idnits 2.17.1 draft-ietf-simple-msrp-acm-10.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 (December 3, 2010) is 4885 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 793 (Obsoleted by RFC 9293) -- 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-11 Summary: 1 error (**), 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: June 6, 2011 Ericsson AB 6 December 3, 2010 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-ietf-simple-msrp-acm-10.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 Transmission Control Protocol (TCP) connection, 20 in order for MSRP messages to 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 June 6, 2011. 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 . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 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 User Agent (UA) which sends the 81 Session Description Protocol (SDP) offer is "active", and it is 82 responsible for creating the MSRP transport connection towards the 83 remote UA if a new connection is required. The core specification 84 also allows, but does not define, alternate mechanisms for MSRP UAs 85 to create MSRP transport connections. 87 [RFC4145] defines a connection-oriented media (COMEDIA) mechanism, 88 that endpoints can use to negotiate the endpoint which initiates the 89 creation of media transport connection. 91 COMEDIA is especially useful when one of the endpoints is located 92 behind a Network Address Translator (NAT). The endpoint can use the 93 mechanism to indicate that it will create the media transport 94 connection, in order for the media to traverse the NAT without the 95 usage of relays, without being required to support more complex 96 mechanisms (e.g. TCP Candidates with Interactive Connectivity 97 Establishment (ICE) [I-D.ietf-mmusic-ice-tcp]). In addition, COMEDIA 98 allows the usage of identical procedures in establishing Transmission 99 Control Protocol (TCP) [RFC0793] connections for different types of 100 media. 102 An example is the Open Mobile Alliance (OMA) defined "Instant Message 103 using SIMPLE" [OMA-TS-SIMPLE_IM-V1_0-20090901-D], where one MSRP UA 104 of every MSRP transport connection represents a media server, which 105 is always located in the carrier network. The media server has a 106 globally reachable IP address and handles application specific policy 107 control as well as NAT traversal. The OMA IM (Instant Messenger) 108 uses COMEDIA for NAT traversal, and all OMA IM MSRP clients support 109 COMEDIA. 111 This document defines how an MSRP UA uses COMEDIA in order to 112 negotiate which UA will create the MSRP transport TCP connection 113 towards the other UA. The document also defines how an MSRP UA which 114 uses COMEDIA can establish an MSRP transport connection with a remote 115 UA that does not support COMEDIA. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Applicability statement 125 Support of this specification is OPTIONAL for MSRP user agents in 126 general. User Agents that are likely to be deployed in networks with 127 NATs SHOULD support this specification. It will improve the odds of 128 being able to make TCP connections successfully traverse NATs, since 129 User Agents behind NATs can be requested to initiate the 130 establishment of the TCP connections. 132 4. COMEDIA for MSRP 134 4.1. General 136 This section defines how an MSRP UA that supports this specification 137 uses the COMEDIA SDP attributes defined in [RFC4145]. 139 4.2. a=setup 141 4.2.1. General 143 An MSRP UA uses the SDP a=setup attribute [RFC4145], in order to 144 negotiate which endpoint will create the MSRP transport connection 145 towards the other UA. 147 An MSRP UA MUST always include an explicit a=setup attribute in its 148 SDP offers and answers, since it might be 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. An MSRP UA MUST NOT send the "holdconn" attribute 154 value. If MSRP UA receives the "holdconn" attribute value it MUST 155 ignore it and process the message as if it did not contain an a=setup 156 attribute. 158 4.2.2. Attribute usage 160 When the a=setup attribute value is "actpass" or "passive", the IP 161 address and port values in the MSRP URI of the SDP a=path attribute 162 MUST contain the actual address and port values on which the UA can 163 receive a TCP connection for the MSRP transport connection. 165 In accordance with [RFC4145], if the a=setup attribute value is 166 "active", the port number value should be 9. 168 If an MSRP UA can provide a globally reachable IP address that the 169 other endpoint can use as destination for a TCP connection, the UA 170 MUST use the a=setup "actpass" attribute value in SDP offers. This 171 is in order to allow the remote UA to send an SDP answer with an 172 a=setup "active" attribute value if the UA is located behind NAT, and 173 in order to be compatible with UAs that do not support COMEDIA and 174 thus always will act as passive endpoints. If an MSRP UA cannot 175 provide the actual transport address, the UA MUST use the a=setup 176 "active" attribute value. 178 The UA MUST NOT use the a=setup "passive" attribute value in an SDP 179 offer. 181 The MSRP UA can determine that it provides a globally reachable IP 182 address in the following scenarios: 184 - the UA can determine that it is not located behind a NAT; 186 - the UA relays its MSRP transport connections via a relay (e.g. 187 MSRP relay or TURN server); or 189 - the UA has used Session Traversal Utilities for NAT (STUN) 190 [RFC5389] signaling to retrieve NAT address and port through the 191 local port to be used for the eventual transport connection, while 192 also having determined that the NAT has endpoint independent mapping 193 and filtering behavior [RFC5382], e.g. using the mechanism defined in 194 [RFC5780]. 196 Some UAs can determine whether the SIP [RFC3261] signaling has 197 traversed a NAT by inspecting the SIP Via header field in the 200 198 (OK) response to the initial SIP REGISTER request, and comparing the 199 IP addresses in the Via sent-by and the received header field 200 parameters. If the IP addresses are not the same then the UA can 201 determine that there is a NAT in the path. Even though the media 202 transport might not traverse the NAT, it is safe to assume that it 203 will, and set the a=setup attribute accordingly. This comparing 204 mechanism does not work in all scenarios, though. For example, if 205 SIP a requests crosses a SIP proxy before crossing a NAT, the UA will 206 not be able to detect the NAT by comparing the IP addresses. 208 If an SDP offer includes an a=setup "actpass" attribute value, the 209 SDP answerer MAY include an a=setup "active" attribute value in the 210 SDP answer, but SHOULD include a=setup "passive" attribute value if 211 it knows that it is not located behind a NAT. 213 Once the active UA has established the MSRP transport connection, the 214 UA must immediately send an MSRP SEND request, as defined in 215 [RFC4975]. 217 NOTE: According to [RFC4975] the initiating UA is always active, but 218 when COMEDIA is used the a=setup attribute is used to negotiate which 219 UA becomes active. 221 4.3. TLS 223 If an MSRP UA conformant to this document uses TLS, it MUST use the 224 TLS mechanisms defined in [RFC4975] and [RFC4976]. 226 According to [RFC4975], the connection can be established with or 227 without TLS mutual authentication. In case mutual authentication is 228 not used, the listening device waits until it receives a request on 229 the connection, at which time it infers the identity of the 230 connecting device from the associated session description. From TLS 231 authentication point of view it is thus irrelevant whether an 232 endpoint takes the active or passive role. 234 If an MSRP UA uses a self-signed TLS certificate to authenticate 235 itself to MSRP peers it also includes its certificate fingerprint in 236 the SDP. 238 Note that fingerprints can only be exchanged in peer-to-peer 239 communication, as MSRP relays [RFC4976] will not receive the SDP 240 payloads containing the fingerprint attributes. 242 4.4. a=connection 244 MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] 245 defines connection reuse procedures for MSRP, and this document does 246 not modify those procedures. 248 If an MSRP UA receives an a=connection attribute, the UA MUST ignore 249 it. 251 4.5. MSRP relay connection 253 If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST 254 always initiate a transport connection towards the relay, no matter 255 what value the client has provided in the a=setup attribute. 257 NOTE: Even if an MSRP UA initiates the TCP connection towards its 258 relay, the UA will only send a SEND request if the UA is active, 259 based on the COMEDIA negotiation. 261 5. Interoperability with connection model defined in RFC 4975 263 An MSRP UA conformant to this document can interoperate with a UA 264 that follows the connection model defined in [RFC4975]. However, if 265 an MSRP UA conformant to this document is located behind NAT, and 266 does not proxy its MSRP communication via an MSRP relay, and the UA 267 receives an SDP offer from a remote UA that follows the connection 268 model defined in [RFC4975], NAT traversal can only be achieved if the 269 MSRP UA supports ICE [I.D.ietf-mmusic-ice-tcp], or if the network 270 supports Session Border Controller (SBC) assisted NAT traversal for 271 TCP. 273 6. Security Considerations 275 According to the connection model defined in [RFC4975], the MSRP UA 276 that sends the SDP offer becomes the active party, and it is 277 responsible for creating the MSRP transport connection towards the 278 remote UA if a new connection is required. 280 When COMEDIA is used, either the sender or the receiver of the SDP 281 offer can become the active party. [RFC4975] requires that the 282 active party immediately issues an MSRP SEND request once the 283 connection has been established. This allows the passive party to 284 bind the inbound TCP connection to the message session identified by 285 the session id part of its MSRP URI. The use of COMEDIA does not 286 change this requirement, but the sender of the SDP offer is no longer 287 assumed to always become the active party. 289 The active party also takes the role as TLS client, if TLS is used to 290 protect the MSRP messages. However, there are no procedures in 291 [RFC4975] that would break in case the receiver of the SDP offer 292 takes the role as TLS client, and the level of security provided by 293 TLS is not affected. 295 7. IANA Considerations 297 This document has no actions for IANA. 299 8. Acknowledgements 301 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 302 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 303 Schubert for their guidance and input in order to produce this 304 document. 306 9. Change Log 308 [RFC EDITOR NOTE: Please remove this section when publishing] 309 Changes from draft-ietf-simple-msrp-acm-09 310 o Changes based on IESG comments. 311 o 30.11.2012: Sean Turner 312 o 30.11.2010: Lars Eggert 313 o 02.12.2012: Adrian Farrel 314 o 03.12.2012: Jari Arkko 315 o TCP reference added. 317 Changes from draft-ietf-simple-msrp-acm-08 318 o Changes based on comments from Gonzalo Camarillo. 320 Changes from draft-ietf-simple-msrp-acm-07 321 o WGLC editorial changes. 323 Changes from draft-ietf-simple-msrp-acm-06 324 o WGLC changes. 326 Changes from draft-ietf-simple-msrp-acm-05 327 o TLS section modified. 329 Changes from draft-ietf-simple-msrp-acm-04 330 o TLS section modified. 331 o Security considerations section modified. 333 Changes from draft-ietf-simple-msrp-acm-03 334 o Changes based on WGLC comments from Adam Roach and Ben Campbell. 335 o New section added related to interoperability with connection 336 model defined in RFC 4975. 337 o Text related to a=setup "holdconn" attribute value removed. 338 o NAT keepalive section removed. 339 o Usage of COMEDIA-TLS removed. 341 Changes from draft-ietf-simple-msrp-acm-02 342 o Changes based on WGLC comments from Salvatore Loreto and Shida 343 Schubert. 345 Changes from draft-ietf-simple-msrp-acm-01 346 o Procedures for using SDP c/m for routing of MSRP messages removed. 347 o Procedures related to modification of MSRP address information by 348 intermediates moved to separate document. 349 o Solution to open issue on usage of the SDP a=connection 350 implemented. 352 10. References 353 10.1. Normative References 355 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 356 RFC 793, September 1981. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 362 the Session Description Protocol (SDP)", RFC 4145, 363 September 2005. 365 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 366 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 368 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 369 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 370 September 2007. 372 10.2. Informative References 374 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 375 A., Peterson, J., Sparks, R., Handley, M., and E. 376 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 377 June 2002. 379 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 380 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 381 RFC 5382, October 2008. 383 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 384 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 385 October 2008. 387 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 388 Using Session Traversal Utilities for NAT (STUN)", 389 RFC 5780, May 2010. 391 [I-D.ietf-mmusic-ice-tcp] 392 Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 393 "TCP Candidates with Interactive Connectivity 394 Establishment (ICE)", draft-ietf-mmusic-ice-tcp-11 (work 395 in progress), November 2010. 397 Authors' Addresses 399 Christer Holmberg 400 Ericsson 401 Hirsalantie 11 402 Jorvas 02420 403 Finland 405 Email: christer.holmberg@ericsson.com 407 Staffan Blau 408 Ericsson AB 409 P.O Box 407 410 Sweden 412 Email: staffan.blau@ericsson.com