Network Working Group R. Denis-Courmont Internet-Draft Nokia Intended status: Experimental September 25, 2007 Expires: March 28, 2008 Connection setup negociation for the Message Session Relay Protocol draft-denis-simple-msrp-comedia-00.txt Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document extends the MSRP connection model to negotiate the direction of the TCP connection setup. This provides a partial yet simple solution for scenarios whereby either, but not both, party to an MSRP session is located behind a NAT or firewall, and cannot serve as the passive endpoint for TCP connection setup. Denis-Courmont Expires March 28, 2008 [Page 1]
Internet-Draft COMEDIA for MSRP September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 4. MSRP COMEDIA Connection Model . . . . . . . . . . . . . . . . . 4 4.1. Offerer processing . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Sending the offer . . . . . . . . . . . . . . . . . . . 4 4.1.2. Receiving the answer . . . . . . . . . . . . . . . . . 5 4.1.3. Setting up the connection . . . . . . . . . . . . . . . 5 4.2. Answerer processing . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Receiving the offer . . . . . . . . . . . . . . . . . . 5 4.2.2. Sending the answer . . . . . . . . . . . . . . . . . . 6 4.2.3. Setting up the connection . . . . . . . . . . . . . . . 6 5. Interactions with MSRP relays . . . . . . . . . . . . . . . . . 6 6. Interactions with TLS . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Denis-Courmont Expires March 28, 2008 [Page 2]
Internet-Draft COMEDIA for MSRP September 2007 1. Introduction MSRP[I-D.ietf-simple-message-sessions] allows transmission of byte streams (such as computer files) between two nodes using a SIP infrastructure. Because reliability and congestion control are required, MSRP uses TCP as its underlying transport protocol. Furthermore, MSRP specifies that the party initiating the session shall act as the active endpoint in establishing the connection- oriented transport session. The answering party shall wait for an incoming connection request, then check the MSRP path header in the first MSRP request, to bind the connection with the SIP dialog. This poses a significant challenge if the answering party is located behind a NAT and/or a stateful firewall. To address these issues, MSRP defines relay nodes (in [I-D.ietf-simple-msrp-relays]), which MSRP clients can use as application-layer proxies. However, deploying these relays bears a significant extra cost, especially as MSRP relays are limitated to a single application-layer protocol (contrary to TURN[I-D.ietf-behave-turn] or SOCKS[RFC1928]). This also constitute a chicken-and-egg problem to MSRP deployment. In addition, MSRP relaying affects the reliability of the data transmission, due to the lack of end-to-end congestion control and reliable end-to-end partial delivery acknowledgement mechanism (partial acknowledgment are optional for receiver to send). This memo proposes an alternative connection model for MSRP that avoids the use of any middlebox when the party initiating the TCP connection is not behind a NAT or a firewall. That also brings reliability and congestion control to MSRP through to the use of an end-to-end TCP session. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Applicability statement Under some usage scenarios, the offerer of an MSRP[I-D.ietf-simple-message-sessions] session description is more likely to be able to receive incoming transport-layer connection requests than the answerer. Some examples scenarios might be: o a MSRP chat server inviting an user to a chat session [I-D.ietf-simple-chat], Denis-Courmont Expires March 28, 2008 [Page 3]
Internet-Draft COMEDIA for MSRP September 2007 o a file being pushed to the receiver [I-D.ietf-mmusic-file-transfer-mech] from a file server, o a SOCKS[RFC1928] proxy, or a TURN relay[I-D.ietf-behave-turn] available to the offerer but not the answerer, o adequate hole punching provision on the offerer side (e.g. with UPnP IGD profile, or manual configuration). In these cases, it would be possible for the answerer to use an MSRP relay[I-D.ietf-simple-msrp-relays], if it cannot receive incoming connection requests, such as if it is located behind a NAT. However, if the offerer can act as the passive side in the establishment of the media connection, the connection setup can be negotiated using COMEDIA[RFC4145]. This has the following advantages: o no need to deploy and provision a MSRP relay, o reliability and congestion control are transparently ensured, as the transport connection is end-to-end, 4. MSRP COMEDIA Connection Model 4.1. Offerer processing 4.1.1. Sending the offer If the offerer of an MSRP session knows that it is prepared to handle transport-layer connection requests, it MUST include the "setup" SDP attribute, as defined in [RFC4145]. It MAY also include the "connection" SDP attribute (to specify whether a transport connection may be re-used), as defined in the same document[RFC4145]. In that case, the setup attribute MUST be set to either "passive" or "actpass". However, for the sake of compatibility with MSRP client which do not implement this specification, it is RECOMMENDED: o that "actpass" be used, rather than "passive", o that the offerer be ready to establish an active connection, as per the basic MSRP connection model. If the offerer is not willing or capable of handling incoming connection requests, it MAY set the setup attribute to "active". If not specified, this is assumed to be the default. For backward compatiblity with MSRP endpoints that do not support the extension specified in this memo, it SHOULD include its actual transport-layer source port number in the offer m= line, rather than specify the port number 9 (discard). The "holdconn" setup type is not defined, and MUST NOT be used. It is left for future specification. Denis-Courmont Expires March 28, 2008 [Page 4]
Internet-Draft COMEDIA for MSRP September 2007 4.1.2. Receiving the answer When the offerer receives a succesful answer, it looks for the setup attribute in the SDP for each media: o If the setup attribute is absent from the answer, and if the offerer had included a setup attribute with the value "passive", the answerer does not support this specification, and the media establishment MUST be considered as failed. o Otherwise, if the setup attribute is absent from the answer, even though the answerer might not support this specification, the COMEDIA connection model can be used (because it is then compatible with the baseline MSRP connection model). o Otherwise, the answerer supports the COMEDIA connection model described in this specification. 4.1.3. Setting up the connection If it has been determined that the connection can be established according to the model described in this memo, the offerer MUST establish the media connection according to [RFC4145], with the following exception: If the offerer is the passive connection endpoint, the source address of the active connection endpoint would normally be found in the relevant c= SDP line, as well as in MSRP path line. However, if a NAT device is present on the path, these addresses might not match the IP address and port numbers of the actual TCP packets. To compensate for this inconsistency, the offerer MUST ignore the address found in the c= and a=path: SDP lines. Instead, it MUST check the From-Path and To-Path fields from the first received MSRP request received through the TCP session. To protect against a potential denial of service, it might need to process multiple incoming TCP sessions, until one of them has been authenticated. 4.2. Answerer processing 4.2.1. Receiving the offer When a MSRP client receives a MSRP session offer, and determines that it will accept the offer, it looks for the setup attribute. o If it is absent, or its value is active, the client MUST follow the normal MSRP connection model. o If the value is "passive", the answerer MUST initiate the TCP connection to the offerer, as specified in [RFC4145]. It will still need to process other SDP parameters (such as "a=accept- bytes") as specified in [I-D.ietf-simple-message-sessions]. In Denis-Courmont Expires March 28, 2008 [Page 5]
Internet-Draft COMEDIA for MSRP September 2007 particular, it needs to cross-match the MSRP a=path SDP attribute with the From-Path headers used in the received MSRP messages. o If the value is "actpass", it MUST choose either of two above connection models, and send format its answer accordingly as specified above. In particular, if it is known that connection requests cannot be processed by the answerer, it SHOULD act as the active endpoint. Similarly, if it is known that connection requests can be processed efficiently (i.e. not using any relaying protocol), it SHOULD act as the passive endpoint. 4.2.2. Sending the answer If the answerer is to initiate the TCP connection (as per the rules set above), it MUST include a COMEDIA setup attribute with a value of "active" in the answer SDP which it sends back to the offerer. It MUST also format the c= and m= line as specified in [RFC4145]. 4.2.3. Setting up the connection Once the TCP session is established, and if the answerer was the active connection endpoint, it MUST send an MSRP request. In particular, if it has no pending data to send, it MUST send an empty MSRP SEND request. That is necessary for the other endpoint to authenticate this TCP session. Some extension to this specification MAY specify other methods to authenticate the peer, (see also [I-D.niemi-simple-msrp-ice]). 5. Interactions with MSRP relays It is not possible to use the MSRP COMEDIA connection model as defined in this memo, and one or more MSRP relays[I-D.ietf-simple-msrp-relays] for a given MSRP session. Whenever the offerer uses a MSRP relay, then it MUST NOT advertise support of the MSRP COMEDIA connection model. Instead, it MUST follow the baseline MSRP connection model. Whenever the answerer detects a MSRP media with a COMEDIA "a=setup" SDP parameter within an offer, while it wants to use a MSRP relay, it MUST discard the "a=setup" attribute in the offer. Note that the discarded "a=setup" SDP attribute might still apply to any other media in the same offer, if there are more than one m= lines in the SDP offer. Denis-Courmont Expires March 28, 2008 [Page 6]
Internet-Draft COMEDIA for MSRP September 2007 6. Interactions with TLS If an MSRP connection that is negotiated using the mechanism described in section Section 4, uses the Transport Layer Security protocol, the Client and Server TLS roles MUST negotiate the relevant parameter as specified per COMEDIA-TLS[RFC4572]. In addition, the MSRP "a=path" attribute MUST specify "msrps" as the URI scheme, consistent with [I-D.ietf-simple-message-sessions]. If TLS is not used, the URI scheme would be "msrp". 7. Security Considerations TBD. 8. IANA Considerations This document raises no new IANA considerations. 9. Acknowledgments The authors would like to thank Christian Schmidt, Bernhard Boehmer, Miguel Garcia, Thomas Theimer, Ivo Sedlacek and Markku Vimpari for their comments on this document. 10. References 10.1. Normative References [I-D.ietf-simple-message-sessions] Campbell, B., "The Message Session Relay Protocol", draft- ietf-simple-message-sessions-19 (work in progress), February 2007. [I-D.ietf-simple-msrp-relays] Jennings, C., "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", draft-ietf- simple-msrp-relays-10 (work in progress), December 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4145] Yon, D. and G. Camarillo, "TCP- Based Media Transport in the Denis-Courmont Expires March 28, 2008 [Page 7]
Internet-Draft COMEDIA for MSRP September 2007 Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4572] Lennox, J., "Connection- Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. 10.2. Informative References [I-D.ietf-behave-turn] Rosenberg, J., "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-04 (work in progress), July 2007. [I-D.ietf-mmusic-file-transfer-mech] Garcia-Martin, M., "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", draft- ietf-mmusic-file-transfer-mech- 03 (work in progress), June 2007. [I-D.ietf-simple-chat] Niemi, A. and M. Garcia-Martin, "Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)", draft-ietf-simple-chat-00 (work in progress), June 2007. [I-D.niemi-simple-msrp-ice] Niemi, A., "Message Session Relay Protocol Adaptation for Interactive Connectivity Establishment (ICE)", draft-niemi-simple-msrp-ice-00 (work in progress), February 2007. [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version Denis-Courmont Expires March 28, 2008 [Page 8]
Internet-Draft COMEDIA for MSRP September 2007 5", RFC 1928, March 1996. Author's Address Remi Denis-Courmont Nokia Technology Platforms P.O. Box 407 Nokia Group FIN-00045 Finland Phone: +358 50 487 6315 EMail: remi.denis-courmont@nokia.com Denis-Courmont Expires March 28, 2008 [Page 9]
Internet-Draft COMEDIA for MSRP September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Denis-Courmont Expires March 28, 2008 [Page 10]