idnits 2.17.1 draft-ietf-simple-msrp-acm-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2010) is 5206 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) == Unused Reference: 'I-D.ietf-mmusic-ice-tcp' is defined on line 328, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-08 Summary: 3 errors (**), 0 flaws (~~), 3 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: July 21, 2010 Ericsson AB 6 January 17, 2010 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-ietf-simple-msrp-acm-04.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 NATs to 18 negotiate which UA will initiate the establishment of the TCP 19 connection, in order for MSRP messages to traverse the NAT. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on July 21, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 64 4. COMEDIA for MSRP . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. a=setup . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.4. a=connection . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.5. MSRP relay connection . . . . . . . . . . . . . . . . . . . 6 70 5. Interoperability with connection model defined in RFC 4975 . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 73 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The Message Session Relay Protocol (MSRP) core specification 82 [RFC4975] defines that the MSRP UA which sends the SDP offer is 83 "active", and it is responsible for creating the MSRP transport 84 connection towards the remote UA if a new connection is required. 85 The core specifcation also allows, but does not define, alternate 86 mechanisms for MSRP UAs to create MSRP transport connections. 88 [RFC4145] defines a connection-oriended media mechanism, COMEDIA, 89 that endpoints can use to negotiate the endpoint which initiates the 90 creation of media transport connection. 92 COMEDIA is especially useful when an endpoint is located behind a 93 NAT. The endpoint can use the mechanism to indicate that it will 94 create the media transport connection, in order for the media to 95 traverse the NAT without the usage of relays. 97 An example is the Open Mobile Alliance (OMA) defined "Instant Message 98 using SIMPLE" [OMA-TS-SIMPLE_IM-V1_0-20090901-D], where one MSRP UA 99 of every MSRP transport connection represents a media server, which 100 is always located in the carrier network. The media server has a 101 global IP address and handles application specific policy control as 102 well as NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA 103 for NAT traversal, and all OMA IM MSRP clients support COMEDIA. 105 This document defines how an MSRP UA uses COMEDIA in order to 106 negotiate which UA will create the MSRP transport TCP connection 107 towards the other UA. The document also defines how an MSRP UA which 108 uses COMEDIA can establish an MSRP transport connection with a remote 109 UA that does not support COMEDIA. 111 2. Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in BCP 14, RFC 2119 116 [RFC2119]. 118 3. Applicability statement 120 Support of this specification is optional for MSRP user agents in 121 general. User Agents that are likely to be deployed in networks 122 where User Agents need to establish the TCP connections in order to 123 traverse NATs SHOULD support this specification in order to improve 124 the odds of being able to communicate across NATs. 126 4. COMEDIA for MSRP 128 4.1. General 130 This section defines how an MSRP UA uses the COMEDIA SDP attributes 131 defined in [RFC4145]. 133 4.2. a=setup 135 An MSRP UA MUST support the SDP a=setup attribute [RFC4145], in order 136 to negotiate which endpoint will create the MSRP transport connection 137 towards the other UA. 139 The a=setup attribute is particularly useful when one MSRP UA 140 represents a network media server, or any other entity that is not 141 located behind a NAT. The a=setup attribute allows the media server 142 to ensure that MSRP UAs create the MSRP transport connections towards 143 the server, so that NATs at user's premises will not interfere with 144 the connection creation. 146 An MSRP UA MUST always include an explicit a=setup attribute in its 147 SDP offers and answers, since it is sometimes useful for the other 148 endpoint, or for entities in the network, to know whether the UA 149 supports COMEDIA or not. 151 An MSRP UA MUST support the a=setup "active", "actpass" and "passive" 152 attribute values. 154 When the a=setup attribute value is "actpass" or "passive", the IP 155 address:port value in the MSRP URI of the SDP a=path attribute MUST 156 contain the actual address:port on which the UA can receive a TCP 157 Open request for the MSRP transport connection. 159 If the a=setup attribute value is "active", the port number value 160 MUST either be the actual port number that the MSRP UA will use for 161 the TCP endpoint, or the port value 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 MSRP UAs that do not support COMEDIA and thus always 169 will act as passive endpoints. If an MSRP UA cannot provide the 170 actual transport address, the UA MUST use the a=setup "active" 171 attribute 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 Simple Traversal of UDP Through NATs (STUN) 185 [RFC3489] signalling to retrieve NAT address:port through the local 186 port to be used for the the eventual transport connection, while also 187 having determined that the NAT is not address restricted. 189 Some UAs can determinte 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 the NAT contains a SIP proxy, the UA will not be able to detect the 199 NAT by comparing the IP addresses." 201 NOTE: If the NAT contains a SIP proxy, the UA will not be able to 202 detect the NAT by comparing the IP addresses. 204 If an SDP offer includes an a=setup "actpass" attribute value, the 205 SDP answer MAY include an a=setup "active" attribute value, but 206 SHOULD include a=setup "passive" attribute value if the SDP answerer 207 knows that it is not located behind a NAT. 209 Once the active UA has established the MSRP transport connection, the 210 UA MUST immediately send an MSRP SEND request, as defined in 211 [RFC4975]. 213 NOTE: According to [RFC4975] the initiating UA is always active, but 214 when COMEDIA is used the a=setup attribute is used to negotiate which 215 UA becomes active. 217 4.3. TLS 219 This document does not specify the usage of COMEDIA-TLS [RFC4572] for 220 MSRP. If an MSRP UA conformant to this document uses TLS, it MUST 221 use the TLS mechanisms defined in [RFC4975] and [RFC4976]. 223 Note that the active UA will take the role of the TLS client, and the 224 passive UA will take the roll of the TLS server. UAs using self- 225 signed TLS certificates SHOULD include certificate fingerprints, as 226 described in section 14.4 of [RFC4975]." 228 4.4. a=connection 230 MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] 231 defines connection reuse procedures for MSRP, and this document does 232 not modify those procedures. 234 If an MSRP UA receives an a=connection attribute, the UA MUST ignore 235 it. 237 4.5. MSRP relay connection 239 If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST 240 always initiate a transport connection towards the relay, no matter 241 what value the client has provided in the a=setup attribute. 243 NOTE: Even if an MSRP UA initiates the TCP connection towards its 244 relay, the UA will only send a SEND request if the UA is active, 245 based on the COMEDIA negotiation. 247 5. Interoperability with connection model defined in RFC 4975 249 An MSRP UA conformant to this document can interoperate with a UA 250 that follows the connection model defined in [RFC4975]. However, if 251 an MSRP UA conformant to this document is located behind NAT, and 252 does not proxy its MSRP communication via an MSRP relay, and the UA 253 receives an SDP offer from a remote UA that follows the connection 254 model defined in [RFC4975], NAT traversal can only be achieved if the 255 MSRP UA supports ICE [I.D.ietf-mmusic-ice-tcp] and the network 256 provides TURN servers, or if the network supports SBC assisted NAT 257 traversal for TCP. 259 6. Security Considerations 261 The procedures define in this document do not impact the security 262 characteristics defined in [RFC4975]. 264 7. Acknowledgements 266 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 267 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 268 Schubert for their guidance and input in order to produce this 269 document. 271 8. Change Log 273 [RFC EDITOR NOTE: Please remove this section when publishing] 275 Changes from draft-ietf-simple-msrp-acm-03 276 o Changes based on WGLC comments from Adam Roach and Ben Campbell. 277 o New section added related to interoperability with connection 278 model defined in RFC 4975. 279 o Text related to a=setup "holdconn" attribute value removed. 280 o NAT keepalive section removed. 281 o Usage of COMEDIA-TLS removed. 283 Changes from draft-ietf-simple-mscp-acm-02 284 o Changes based on WGLC comments from Salvatore Loreto and Shida 285 Schubert. 287 Changes from draft-ietf-simple-msrp-acm-01 288 o Procedures for using SDP c/m for routing of MSRP messages removed. 289 o Procedures related to modification of MSRP address information by 290 intermediates moved to separate document. 291 o Solution to open issue on usage of the SDP a=connection 292 implemented. 294 9. References 296 9.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 302 the Session Description Protocol (SDP)", RFC 4145, 303 September 2005. 305 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 306 Transport Layer Security (TLS) Protocol in the Session 307 Description Protocol (SDP)", RFC 4572, July 2006. 309 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 310 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 312 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 313 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 314 September 2007. 316 9.2. Informative References 318 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 319 "STUN - Simple Traversal of User Datagram Protocol (UDP) 320 Through Network Address Translators (NATs)", RFC 3489, 321 March 2003. 323 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 324 A., Peterson, J., Sparks, R., Handley, M., and E. 325 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 326 June 2002. 328 [I-D.ietf-mmusic-ice-tcp] 329 Perreault, S. and J. Rosenberg, "TCP Candidates with 330 Interactive Connectivity Establishment (ICE)", 331 draft-ietf-mmusic-ice-tcp-08 (work in progress), 332 October 2009. 334 Authors' Addresses 336 Christer Holmberg 337 Ericsson 338 Hirsalantie 11 339 Jorvas 02420 340 Finland 342 Email: christer.holmberg@ericsson.com 344 Staffan Blau 345 Ericsson AB 346 P.O Box 407 347 Sweden 349 Email: staffan.blau@ericsson.com