idnits 2.17.00 (12 Aug 2021) /tmp/idnits54013/draft-denis-simple-msrp-comedia-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 490. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As specified in [RFC4145], the active endpoint MUST use the host/ address and ports as found in the SDP m= and c= line. It SHOULD not match the MSRP path in the SDP a=path: attribute with the m= and c= line. That should allow interoperating with COMEDIA-aware application layer gateways if there is one on the signaling path. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2008) is 5045 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) -- No information found for draft-ietf-behave-turn - is the name correct? == Outdated reference: draft-ietf-mmusic-file-transfer-mech has been published as RFC 5547 == Outdated reference: draft-ietf-simple-chat has been published as RFC 7701 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE R. Denis-Courmont 3 Internet-Draft Nokia 4 Intended status: Experimental July 27, 2008 5 Expires: January 28, 2009 7 Connection setup negociation for the Message Session Relay Protocol 8 draft-denis-simple-msrp-comedia-02.txt 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 28, 2009. 35 Abstract 37 This document extends the MSRP connection model to negotiate the 38 direction of the TCP connection setup. This provides a partial yet 39 simple solution for scenarios whereby either, but not both, party to 40 an MSRP session is located behind a NAT or firewall, and cannot serve 41 as the passive endpoint for TCP connection setup. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Applicability statement . . . . . . . . . . . . . . . . . . . 3 48 4. MSRP COMEDIA Connection Model . . . . . . . . . . . . . . . . 4 49 4.1. Offerer processing . . . . . . . . . . . . . . . . . . . . 4 50 4.1.1. Sending the offer . . . . . . . . . . . . . . . . . . 4 51 4.1.2. Receiving the answer . . . . . . . . . . . . . . . . . 5 52 4.1.3. Setting up the connection . . . . . . . . . . . . . . 5 53 4.2. Answerer processing . . . . . . . . . . . . . . . . . . . 6 54 4.2.1. Receiving the offer . . . . . . . . . . . . . . . . . 6 55 4.2.2. Sending the answer . . . . . . . . . . . . . . . . . . 7 56 4.2.3. Setting up the connection . . . . . . . . . . . . . . 7 57 5. Interactions with MSRP relays . . . . . . . . . . . . . . . . 8 58 6. NAT keep alives . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. COMEDIA extensions . . . . . . . . . . . . . . . . . . . . . . 8 60 7.1. Interactions with TLS . . . . . . . . . . . . . . . . . . 8 61 7.2. Interactions with ICE . . . . . . . . . . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 MSRP[RFC4975] allows transmission of byte streams (such as computer 72 files) between two nodes using a SIP infrastructure. Because 73 reliability and congestion control are required, MSRP uses TCP as its 74 underlying transport protocol. Furthermore, MSRP specifies that the 75 party initiating the session shall act as the active endpoint in 76 establishing the connection-oriented transport session. The 77 answering party shall wait for an incoming connection request, then 78 check the MSRP path header in the first MSRP request, to bind the 79 connection with the SIP dialog. 81 This poses a significant challenge if the answering party is located 82 behind a NAT and/or a stateful firewall. To address these issues, 83 MSRP defines relay nodes (in [RFC4976]), which MSRP clients can use 84 as application-layer proxies. 86 However, deploying these relays bears a significant extra cost, 87 especially as MSRP relays are limitated to a single application-layer 88 protocol (contrary to TURN[I-D.ietf-behave-turn] or SOCKS[RFC1928]). 89 This also constitute a chicken-and-egg problem to MSRP deployment. 91 In addition, MSRP relaying affects the reliability of the data 92 transmission, due to the lack of end-to-end congestion control and 93 reliable end-to-end partial delivery acknowledgement mechanism 94 (partial acknowledgment are optional for receiver to send). 96 This memo proposes an alternative connection model for MSRP. It 97 avoids the use of any middlebox when either party to the MSRP 98 session, is not behind a NAT or a firewall. It also brings 99 reliability and congestion control to MSRP through to the use of an 100 end-to-end TCP session. 102 2. Definitions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Applicability statement 110 Under some usage scenarios, the offerer of an MSRP[RFC4975] session 111 description is more likely to be able to receive incoming transport- 112 layer connection requests than the answerer. Some examples scenarios 113 might be: 115 o a MSRP chat server inviting an user to a chat session 116 [I-D.ietf-simple-chat], 118 o a file being pushed to the receiver 119 [I-D.ietf-mmusic-file-transfer-mech] from a file server, 121 o a SOCKS[RFC1928] proxy, or a TURN relay[I-D.ietf-behave-turn] 122 available to the offerer but not the answerer, 124 o adequate hole punching provision on the offerer side (e.g. with 125 UPnP IGD profile, or manual configuration). 127 In these cases, it would be possible for the answerer to use an MSRP 128 relay[RFC4976], if it cannot receive incoming connection requests, 129 such as if it is located behind a NAT. 131 However, if the offerer can act as the passive side in the 132 establishment of the media connection, the connection setup can be 133 negotiated using COMEDIA[RFC4145]. This has the following 134 advantages: 136 o no need to deploy and provision a MSRP relay, 138 o reliability and congestion control are transparently ensured, as 139 the transport connection is end-to-end, 141 4. MSRP COMEDIA Connection Model 143 4.1. Offerer processing 145 4.1.1. Sending the offer 147 If the offerer of an MSRP session knows that it is prepared to handle 148 transport-layer connection requests, it MUST include the "setup" SDP 149 attribute, as defined in [RFC4145]. It MAY also include the 150 "connection" SDP attribute (to specify whether a transport connection 151 may be re-used), as defined in the same document[RFC4145]. 153 In that case, the setup attribute MUST be set to either "passive" or 154 "actpass". However, for the sake of compatibility with MSRP client 155 which do not implement this specification, it is RECOMMENDED: 157 o that "actpass" be used, rather than "passive", 159 o that the offerer be ready to establish an active connection, as 160 per the basic MSRP connection model. 162 The following example shows an exerpt of an SDP offer using COMEDIA: 164 v=0 165 o=alice 8459831645 4643536435 IN IP4 alice.example.com 166 s= - 167 c=IN IP4 alice.example.com 168 t=0 0 169 m=message 4535 TCP/MSRP * 170 a=setup:actpass 171 a=connection:new 172 ... other session attributes ... 174 Offer example 176 If the offerer is not willing or capable of handling incoming 177 connection requests, it MAY set the setup attribute to "active". If 178 not specified, this is assumed to be the default. For backward 179 compatiblity with MSRP endpoints that do not support the extension 180 specified in this memo, it SHOULD include its actual transport-layer 181 source port number in the offer m= line, rather than specify the port 182 number 9 (discard). 184 The "holdconn" setup type is not defined, and MUST NOT be used. It 185 is left for future specification. 187 4.1.2. Receiving the answer 189 When the offerer receives a succesful answer, it looks for the setup 190 attribute in the SDP for each media: 192 o If the setup attribute is absent from the answer, and if the 193 offerer had included a setup attribute with the value "passive", 194 the answerer does not support this specification, and the media 195 establishment MUST be considered as failed. 197 o Otherwise, if the setup attribute is absent from the answer, even 198 though the answerer might not support this specification, the 199 COMEDIA connection model can be used (because it is then 200 compatible with the baseline MSRP connection model). 202 o Otherwise, the answerer supports the COMEDIA connection model 203 described in this specification. 205 4.1.3. Setting up the connection 207 If it has been determined that the connection can be established 208 according to the model described in this memo, the offerer MUST 209 establish the media connection according to [RFC4145], with the 210 following exception: 212 The source address of the active connection endpoint would normally 213 be found in the relevant c= line, as well as in MSRP path line from 214 the SDP. However, if a NAT device is present on the media path, 215 these addresses might not match the IP address and port numbers of 216 the actual TCP packets. To compensate for this inconsistency, the 217 passive endpoint MUST ignore the address found in the c= and a=path: 218 SDP lines, and accept incoming TCP connection requests from any 219 remote peer. 221 To protect against a potential denial of service, the passive peer 222 might need to process multiple incoming TCP sessions, until one of 223 them has been authenticated. The legitimate TCP session MUST be 224 authenticated by checking the From-Path and To-Path fields from MSRP 225 requests received through that TCP session. 227 As specified in [RFC4145], the active endpoint MUST use the host/ 228 address and ports as found in the SDP m= and c= line. It SHOULD not 229 match the MSRP path in the SDP a=path: attribute with the m= and c= 230 line. That should allow interoperating with COMEDIA-aware 231 application layer gateways if there is one on the signaling path. 233 4.2. Answerer processing 235 4.2.1. Receiving the offer 237 When a MSRP client receives a MSRP session offer, and determines that 238 it will accept the offer, it looks for the setup attribute. 240 o If it is absent, or its value is active, the client MUST follow 241 the normal MSRP connection model. 243 o If the value is "passive", the answerer MUST initiate the TCP 244 connection to the offerer, as specified in [RFC4145]. It will 245 still need to process other SDP parameters (such as "a=accept- 246 bytes") as specified in [RFC4975]. In particular, it needs to 247 cross-match the MSRP a=path SDP attribute with the From-Path 248 headers used in the received MSRP messages. 250 o If the value is "actpass", it MUST choose either of two above 251 connection models, and send format its answer accordingly as 252 specified above. In particular, if it is known that connection 253 requests cannot be processed by the answerer, it SHOULD act as the 254 active endpoint. Similarly, if it is known that connection 255 requests can be processed efficiently (i.e. not using any relaying 256 protocol), it SHOULD act as the passive endpoint. 258 4.2.2. Sending the answer 260 If the answerer is to initiate the TCP connection (as per the rules 261 set above), it MUST include a COMEDIA setup attribute with a value of 262 "active" in the answer SDP which it sends back to the offerer (see 263 example below). It MUST also format the c= and m= line as specified 264 in [RFC4145]. 266 v=0 267 o=alice 3245439832 1457605654 IN IP4 bob.example.com 268 s= - 269 c=IN IP4 bob.example.com 270 t=0 0 271 m=message 9 TCP/MSRP * 272 a=setup:active 273 a=connection:new 274 ... other session attributes ... 276 Active setup answer example 278 Otherwise, the answerer MAY include a COMEDIA setup attribute with a 279 value of "passive", as in the following example: 281 v=0 282 o=alice 3245439832 1457605654 IN IP4 bob.example.com 283 s= - 284 c=IN IP4 bob.example.com 285 t=0 0 286 m=message 34567 TCP/MSRP * 287 a=setup:active 288 a=connection:new 289 ... other session attributes ... 291 Passive setup answer example 293 4.2.3. Setting up the connection 295 Once the TCP session is established, and if the answerer was the 296 active connection endpoint, it MUST send an MSRP request. In 297 particular, if it has no pending data to send, it MUST send an empty 298 MSRP SEND request. That is necessary for the other endpoint to 299 authenticate this TCP session. 301 Some extension to this specification MAY specify other methods to 302 authenticate the peer, (see also [I-D.niemi-simple-msrp-ice]). 304 5. Interactions with MSRP relays 306 It is not possible to use the MSRP COMEDIA connection model as 307 defined in this memo, and one or more MSRP relays[RFC4976] for a 308 given MSRP session. 310 Whenever the offerer uses a MSRP relay, then it MUST NOT advertise 311 support of the MSRP COMEDIA connection model. Instead, it MUST 312 follow the baseline MSRP connection model. 314 Whenever the answerer detects a MSRP media with a COMEDIA "a=setup" 315 SDP parameter within an offer, while it wants to use a MSRP relay, it 316 MUST discard the "a=setup" attribute in the offer. Note that the 317 discarded "a=setup" SDP attribute might still apply to any other 318 media in the same offer, if there are more than one m= lines in the 319 SDP offer. 321 6. NAT keep alives 323 The MSRP protocol does not allow leading CRLF (contrary to e.g., HTTP 324 or SIP). If a keep-alive is required, a dummy MSRP SEND request 325 SHOULD be sent, similar to when establishing a new MSRP connection. 327 It should be noted that sending frequent keep-alives may have very 328 adverse effect when used with certain network access technologies 329 (such as 3G cellular), such as dramatic increase of current drain. 330 As TCP bindings tend to have much longer expiration timers than UDP, 331 on middleboxes, sending of keep-alives might not be as critical as 332 with a UDP-based protocol. 334 7. COMEDIA extensions 336 7.1. Interactions with TLS 338 If an MSRP connection that is negotiated using the mechanism 339 described in section Section 4, uses the Transport Layer Security 340 protocol, the Client and Server TLS roles MUST negotiate the relevant 341 parameter as specified per COMEDIA-TLS[RFC4572]. 343 In addition, the MSRP "a=path" attribute MUST specify "msrps" as the 344 URI scheme, consistent with [RFC4975]. If TLS is not used, the URI 345 scheme would be "msrp". 347 7.2. Interactions with ICE 349 ICE-TCP can be used as is with the MSRP COMEDIA, as it is an 350 extension to COMEDIA. 352 8. Security Considerations 354 TBD. 356 9. IANA Considerations 358 This document raises no new IANA considerations. 360 10. Acknowledgments 362 The authors would like to thank Christian Schmidt, Bernhard Boehmer, 363 Miguel Garcia, Thomas Theimer, Ivo Sedlacek, Markku Vimpari and 364 Thomas Belling for their comments on this document. 366 11. References 368 11.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use 371 in RFCs to Indicate Requirement 372 Levels", BCP 14, RFC 2119, 373 March 1997. 375 [RFC4145] Yon, D. and G. Camarillo, "TCP- 376 Based Media Transport in the 377 Session Description Protocol 378 (SDP)", RFC 4145, 379 September 2005. 381 [RFC4572] Lennox, J., "Connection- 382 Oriented Media Transport over 383 the Transport Layer Security 384 (TLS) Protocol in the Session 385 Description Protocol (SDP)", 386 RFC 4572, July 2006. 388 [RFC4975] Campbell, B., Mahy, R., and C. 389 Jennings, "The Message Session 390 Relay Protocol (MSRP)", 391 RFC 4975, September 2007. 393 [RFC4976] Jennings, C., Mahy, R., and A. 394 Roach, "Relay Extensions for 395 the Message Sessions Relay 396 Protocol (MSRP)", RFC 4976, 397 September 2007. 399 11.2. Informative References 401 [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. 402 Matthews, "Traversal Using 403 Relays around NAT (TURN): Relay 404 Extensions to Session 405 Traversal Utilities for NAT 406 (STUN)", 407 draft-ietf-behave-turn-09 (work 408 in progress), July 2008. 410 [I-D.ietf-mmusic-file-transfer-mech] Garcia-Martin, M., Isomaki, M., 411 Camarillo, G., Loreto, S., and 412 P. Kyzivat, "A Session 413 Description Protocol (SDP) 414 Offer/Answer Mechanism to 415 Enable File Transfer", draft- 416 ietf-mmusic-file-transfer-mech- 417 08 (work in progress), 418 May 2008. 420 [I-D.ietf-simple-chat] Niemi, A., Garcia-Martin, M., 421 and G. Sandbakken, "Multi-party 422 Instant Message (IM) Sessions 423 Using the Message Session Relay 424 Protocol (MSRP)", 425 draft-ietf-simple-chat-02 (work 426 in progress), February 2008. 428 [I-D.niemi-simple-msrp-ice] Niemi, A., "Message Session 429 Relay Protocol Adaptation for 430 Interactive Connectivity 431 Establishment (ICE)", 432 draft-niemi-simple-msrp-ice-00 433 (work in progress), 434 February 2007. 436 [RFC1928] Leech, M., Ganis, M., Lee, Y., 437 Kuris, R., Koblas, D., and L. 438 Jones, "SOCKS Protocol Version 439 5", RFC 1928, March 1996. 441 Author's Address 443 Remi Denis-Courmont 444 Nokia Technology Platforms 445 P.O. Box 407 446 Nokia Group FIN-00045 447 Finland 449 Phone: +358 50 487 6315 450 EMail: remi.denis-courmont@nokia.com 452 Full Copyright Statement 454 Copyright (C) The IETF Trust (2008). 456 This document is subject to the rights, licenses and restrictions 457 contained in BCP 78, and except as set forth therein, the authors 458 retain all their rights. 460 This document and the information contained herein are provided on an 461 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 462 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 463 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 464 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 465 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 466 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 468 Intellectual Property 470 The IETF takes no position regarding the validity or scope of any 471 Intellectual Property Rights or other rights that might be claimed to 472 pertain to the implementation or use of the technology described in 473 this document or the extent to which any license under such rights 474 might or might not be available; nor does it represent that it has 475 made any independent effort to identify any such rights. Information 476 on the procedures with respect to rights in RFC documents can be 477 found in BCP 78 and BCP 79. 479 Copies of IPR disclosures made to the IETF Secretariat and any 480 assurances of licenses to be made available, or the result of an 481 attempt made to obtain a general license or permission for the use of 482 such proprietary rights by implementers or users of this 483 specification can be obtained from the IETF on-line IPR repository at 484 http://www.ietf.org/ipr. 486 The IETF invites any interested party to bring to its attention any 487 copyrights, patents or patent applications, or other proprietary 488 rights that may cover technology that may be required to implement 489 this standard. Please address the information to the IETF at 490 ietf-ipr@ietf.org.