idnits 2.17.1 draft-ietf-simple-msrp-acm-03.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 'Intended status' indicated for this document; assuming Proposed Standard 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 (December 17, 2009) is 5216 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: 'RFC2606' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-ice' is defined on line 307, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 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 Ericsson 4 Expires: June 20, 2010 S. Blau 5 Ericsson AB 6 December 17, 2009 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-ietf-simple-msrp-acm-03.txt 12 Abstract 14 This document defines an alternative connection model for MSRP UAs, 15 which uses COMEDIA in order to create the MSRP transport connection. 16 The model allows MSRP UAs behind NATs to negotiate which UA will 17 initiate the establishment of the TCP connection, in order for MSRP 18 messages to traverse the NAT. The document also defines how an MSRP 19 UA which is located behind a NAT keeps the NAT binding alive. 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 June 20, 2010. 44 Copyright Notice 46 Copyright (c) 2009 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. NAT keepalive . . . . . . . . . . . . . . . . . . . . . . . . . 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 [RFC4975] defines that the MSRP UA which sends the SDP offer is 82 "active", and it is responsible to create the MSRP transport 83 connection towards the remote UA if a new connection is required. 84 [RFC4975] allows other mechanisms to be used to create MSRP transport 85 connection, but does not define any other mechanisms. 87 [RFC4145] defines a mechanism, COMEDIA, which endpoints can use to 88 negotiate the endpoint which initiates the creation of media 89 transport connection. 91 COMEDIA is especially useful when an endpoint is located behind a 92 NAT. The endpoint can use the mechanism to indicate that it will 93 create the media transport connection, in order for the media to 94 traverse the NAT without the usage of relays. 96 An example is the OMA (Open Mobile Alliance) defined "Instant Message 97 using SIMPLE" [OMA-TS-SIMPLE_IM-V1_0-20090901-D], where one MSRP UA 98 of every MSRP transport connection represents a media server, which 99 is always located in the network. The media server has a global IP 100 address and handles application specific policy control as well as 101 NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA for NAT 102 traversal, and all OMA IM MSRP clients support COMEDIA. 104 This document defines how an MSRP UA uses COMEDIA in order to 105 negotiate which UA will create the MSRP transport TCP connection 106 towards the other UA. The document also defines how an MSRP UA which 107 uses COMEDIA can establish an MSRP transport connection with a remote 108 UA that does not support COMEDIA. 110 2. Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14, RFC 2119 115 [RFC2119]. 117 3. Applicability statement 119 An MSRP UA conformant to this document can interop with an [RFC4975] 120 conformant MSRP UA. However, if an MSRP UA conformant to this 121 document is located behind NAT, and does not proxy its MSRP 122 communication via an MSRP-Relay node, and the UA receives an SDP 123 offer from an [RFC4975] conformant remote UA, NAT traversal can only 124 be achieved if the MSRP UA supports ICE and the network provides TURN 125 servers, or if the network supports SBC assisted NAT traversal for 126 TCP. 128 4. COMEDIA for MSRP 130 4.1. General 132 This section defines how an MSRP UA uses the COMEDIA SDP attributes 133 defined in [RFC4145], how an MSRP UA can use the COMEDIA TLS 134 extensions [RFC4572], and how an MSRP UA keeps a NAT binding alive. 136 4.2. a=setup 138 An MSRP UA MUST support the SDP a=setup attribute [RFC4145], in order 139 to negotiate which endpoint will create the MSRP transport connection 140 towards the other UA. 142 The a=setup attribute is particularly useful when one MSRP UA 143 represents a network media server, or any other entity which is not 144 located behind a NAT. The a=setup attribute allows the media server 145 to ensure that MSRP UAs create the MSRP transport connections towards 146 the server, so that NATs at user's premises will not interfere with 147 the connection creation. 149 An MSRP UA MUST always include an explicit a=setup attribute in its 150 SDP offers and answers, since it is sometimes useful for the other 151 endpoint, or for entities in the network, to know whether the UA 152 supports COMEDIA or not. 154 An MSRP UA MUST support the a=setup "active", "actpass" and "passive" 155 attribute values. An MSRP UA MUST NOT use the a=setup "holdcon" 156 attribute value. 158 When the a=setup attribute value is "actpass" or "passive", the IP 159 address:port value in the MSRP URI of the SDP a=path attribute MUST 160 contain the actual address:port on which the UA can receive a TCP 161 Open request for the MSRP transport connection. 163 If the a=setup attribute value is "active", the port number value 164 MUST either be the actual port number that the MSRP UA will use for 165 the TCP endpoint, or the port value 9. 167 If an MSRP UA can provide a global IP address that the other endpoint 168 can use as destination for a TCP Open request, the UA MUST use the 169 a=setup "actpass" attribute value in SDP offers. This is in order to 170 allow the remote UA to send an SDP answer with an a=setup "active" 171 attribute value if the UA is located behind NAT, and in order to be 172 compatible with MSRP UAs that do not support COMEDIA and thus always 173 will act as passive endpoints. If an MSRP UA cannot provide the 174 actual transport address, the UA MUST use the a=setup "active" 175 attribute value. 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 STUN signalling to retrieve NAT address:port 186 through the local port to be used for the the eventual transport 187 connection, while also having determined that the NAT is not address 188 restricted. 190 If an MSRP UA is located behind a NAT, both SIP signaling and MSRP 191 media will pass trough the NAT, and a UA can determine whether the 192 media transport will be NATed by inspecting the SIP Via header in the 193 200 (OK) response if the initial REGISTER request, by comparing the 194 IP addresses in the Via sent-by and received parameters. If these 195 are not the same then the UA can determine that there is a NAT in the 196 path. 198 If an SDP offer includes an a=setup "actpass" attribute value, the 199 SDP answer MAY include an a=setup "active" attribute value, but 200 SHOULD include a=setup "passive" attribute value if the SDP answerer 201 knows that it is not located behind a NAT. 203 Once the active UA has established the MSRP transport connection, the 204 UA MUST immediately send an MSRP SEND request, as defined in 205 [RFC4975]. 207 NOTE: According to [RFC4975] the initiating UA is always active, but 208 when COMEDIA is used the a=setup attribute is used to negotiate which 209 UA becomes active. 211 4.3. TLS 213 If MSRP UAs negotiate a TLS transport connection for MSRP, the role 214 of TLS client and TLS server MUST negotiate the relevant parameter as 215 defined in COMEDIA-TLS [RFC4572], and in accordance with [RFC4975] 216 the MSRP URI scheme SHOULD be msrps and the m-line protocol indicator 217 SHOULD be TCP/TLS/MSRP. 219 4.4. a=connection 221 MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] 222 defines connection reuse procedures for MSRP, and this document does 223 not modify those procedures. 225 If an MSRP UA receives an a=connection attribute, the UA MUST ignore 226 it. 228 NOTE: If an MSRP UA uses ICE [I.D.ietf-mmusic-ice] when it 229 establishes the MSRP transport connection, the UA needs to perform 230 the normal MSRP checks for possible reuse of an existing transport 231 connection before it sends any TCP Open requests. 233 4.5. MSRP relay connection 235 If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST 236 always initiate a transport connection towards the relay, no matter 237 what value the client has provided in the a=setup attribute. 239 NOTE: Even if an MSRP UA initiates the TCP connection towards its 240 relay, the UA will only send a SEND request if the UA is active, 241 based on the COMEDIA negotiation. 243 5. NAT keepalive 245 If an MSRP UA is located behind a NAT the UA MUST keep the NAT 246 binding alive, in accordance with section 10 of [I.D.ietf-mmusic- 247 ice]. The UA SHOULD use the character string CR-LF as NAT keepalive. 248 However, if the NAT traversal method selected by ICE was based on 249 successful connectivity checks, using STUN, then the UA MAY 250 alternatively use STUN as defined in [I.D-ietf-mmusic-ice]. 252 6. Security Considerations 254 The procedures define in this document do not impact the security 255 characteristics defined in [RFC4975]. 257 7. Acknowledgements 259 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 260 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 261 Schubert for their guidance and input in order to produce this 262 document. 264 8. Change Log 266 [RFC EDITOR NOTE: Please remove this section when publishing] 268 Changes from draft-ietf-simple-mscp-acm-02 269 o Changes based on WGLC comments from Salvatore Loreto and Shida 270 Schubert. 272 Changes from draft-ietf-simple-msrp-acm-01 273 o Procedures for using SDP c/m for routing of MSRP messages removed. 274 o Procedures related to modification of MSRP address information by 275 intermediates moved to separate document. 276 o Solution to open issue on usage of the SDP a=connection 277 implemented. 279 9. References 281 9.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 287 Names", BCP 32, RFC 2606, June 1999. 289 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 290 Initiation Protocol (SIP)", RFC 3323, November 2002. 292 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 293 the Session Description Protocol (SDP)", RFC 4145, 294 September 2005. 296 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 297 Transport Layer Security (TLS) Protocol in the Session 298 Description Protocol (SDP)", RFC 4572, July 2006. 300 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 301 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 303 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 304 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 305 September 2007. 307 [I-D.ietf-mmusic-ice] 308 Rosenberg, J., "Interactive Connectivity Establishment 309 (ICE): A Protocol for Network Address Translator (NAT) 310 Traversal for Offer/Answer Protocols", 311 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 313 9.2. Informative References 315 Authors' Addresses 317 Christer Holmberg 318 Ericsson 319 Hirsalantie 11 320 Jorvas 02420 321 Finland 323 Email: christer.holmberg@ericsson.com 325 Staffan Blau 326 Ericsson AB 327 P.O Box 407 328 Sweden 330 Email: staffan.blau@ericsson.com