TOC 
Network Working GroupR. Denis-Courmont
Internet-DraftNokia
Intended status: ExperimentalFebruary 07, 2008
Expires: August 10, 2008 


Connection setup negociation for the Message Session Relay Protocol
draft-denis-simple-msrp-comedia-01.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 August 10, 2008.

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.



Table of Contents

1.  Introduction
2.  Definitions
3.  Applicability statement
4.  MSRP COMEDIA Connection Model
    4.1.  Offerer processing
        4.1.1.  Sending the offer
        4.1.2.  Receiving the answer
        4.1.3.  Setting up the connection
    4.2.  Answerer processing
        4.2.1.  Receiving the offer
        4.2.2.  Sending the answer
        4.2.3.  Setting up the connection
5.  Interactions with MSRP relays
6.  Interactions with TLS
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References




 TOC 

1.  Introduction

MSRP[RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) 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 [RFC4976] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.)), 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] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) or SOCKS[RFC1928] (Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, “SOCKS Protocol Version 5,” March 1996.)). 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. It avoids the use of any middlebox when either party to the MSRP session, is not behind a NAT or a firewall. It also brings reliability and congestion control to MSRP through to the use of an end-to-end TCP session.



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Applicability statement

Under some usage scenarios, the offerer of an MSRP[RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) session description is more likely to be able to receive incoming transport-layer connection requests than the answerer. Some examples scenarios might be:

In these cases, it would be possible for the answerer to use an MSRP relay[RFC4976] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.), 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] (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.). This has the following advantages:



 TOC 

4.  MSRP COMEDIA Connection Model



 TOC 

4.1.  Offerer processing



 TOC 

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] (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.). 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] (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.).

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:

The following example shows an exerpt of an SDP offer using COMEDIA:


v=0
o=alice 8459831645 4643536435 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 4535 TCP/MSRP *
a=setup:actpass
a=connection:new
... other session attributes ...

 Offer example 

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.



 TOC 

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:



 TOC 

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] (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.), 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.



 TOC 

4.2.  Answerer processing



 TOC 

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.



 TOC 

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 (see example below). It MUST also format the c= and m= line as specified in [RFC4145] (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.).


v=0
o=alice 3245439832 1457605654 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 9 TCP/MSRP *
a=setup:active
a=connection:new
... other session attributes ...

 Active setup answer example 

Otherwise, the answerer MAY include a COMEDIA setup attribute with a value of "passive", as in the following example:


v=0
o=alice 3245439832 1457605654 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 34567 TCP/MSRP *
a=setup:active
a=connection:new
... other session attributes ...

 Passive setup answer example 



 TOC 

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] (Niemi, A., “Message Session Relay Protocol Adaptation for Interactive Connectivity Establishment (ICE),” February 2007.)).



 TOC 

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[RFC4976] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.) 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.



 TOC 

6.  Interactions with TLS

If an MSRP connection that is negotiated using the mechanism described in section Section 4 (MSRP COMEDIA Connection Model), uses the Transport Layer Security protocol, the Client and Server TLS roles MUST negotiate the relevant parameter as specified per COMEDIA-TLS[RFC4572] (Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP),” July 2006.).

In addition, the MSRP "a=path" attribute MUST specify "msrps" as the URI scheme, consistent with [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.). If TLS is not used, the URI scheme would be "msrp".



 TOC 

7.  Security Considerations

TBD.



 TOC 

8.  IANA Considerations

This document raises no new IANA considerations.



 TOC 

9.  Acknowledgments

The authors would like to thank Christian Schmidt, Bernhard Böhmer, Miguel Garcia, Thomas Theimer, Ivo Sedlacek and Markku Vimpari for their comments on this document.



 TOC 

10.  References



 TOC 

10.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4145] Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” RFC 4145, September 2005 (TXT).
[RFC4572] Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP),” RFC 4572, July 2006 (TXT).
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT).
[RFC4976] Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” RFC 4976, September 2007 (TXT).


 TOC 

10.2. Informative References

[I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” draft-ietf-behave-turn-16 (work in progress), July 2009 (TXT).
[I-D.ietf-mmusic-file-transfer-mech] Garcia, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, “A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer,” draft-ietf-mmusic-file-transfer-mech-11 (work in progress), February 2009 (TXT).
[I-D.ietf-simple-chat] Niemi, A., Garcia, M., and G. Sandbakken, “Multi-party Chat Using the Message Session Relay Protocol (MSRP),” draft-ietf-simple-chat-06 (work in progress), April 2010 (TXT).
[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 (TXT).
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, “SOCKS Protocol Version 5,” RFC 1928, March 1996 (TXT).


 TOC 

Author's Address

  Rémi 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


 TOC 

Full Copyright Statement

Intellectual Property