SIMPLE D. MacDonald Internet-Draft CounterPath Solutions, Inc. Intended status: Experimental H. Kaplan Expires: January 8, 2009 Acme Packet July 7, 2008 Opaque MSRP Path Uri draft-macdonald-simple-msrp-opaque-path-00 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 January 8, 2009. Abstract The Message Session Relay Protocol(MSRP) does not allow efficient topology hiding, such that MSRP users can hide the IP Address of their systems. This limitation is due to the fact that MSRP Path headers contain physical IP addresses. This document describes a mechanism which adds a level of indirection to allow topology hiding. It defines the option tag msrp-opaque. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this MacDonald & Kaplan Expires January 8, 2009 [Page 1] Internet-Draft Opaque MSRP Path July 2008 document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 3 4. MSRP Opaque URI . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Opaque URI Parameter Format . . . . . . . . . . . . . . . 5 4.2. Generating an Opaque Uri Parameter . . . . . . . . . . . . 5 4.3. MSRP URI Parameter . . . . . . . . . . . . . . . . . . . . 5 5. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Backwards Compatibility with RFC 4975 and 4976 . . . . . . . . 6 7. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 MacDonald & Kaplan Expires January 8, 2009 [Page 2] Internet-Draft Opaque MSRP Path July 2008 1. Applicability This technique may be used in any MSRP deployment where all MSRP endpoints support this extension when routing on an opaque MSRP URI. This document only describes an SDP based mechanism for binding a physical address to an opaque MSRP URI which limits possible topologies. RFC4976 [RFC4976] MSRP relays will not be able to route from opaque MSRP URI's. 2. Introduction A frequent requirement of network architectures is to hide the systems of the core network from user agents. It is also often desirable to hide the IP address of a user agent from other user agents in the network. This is usually accomplished using a SIP B2BUA or other relay element. MSRP does not allow an efficient approach to this problem because the payload of the protocol contains physical IP adresses, and thus the B2BUA needs to modify MSRP messages in order to hide topology information. This specification defines an opague MSRP URI which does not contain a routable IP address. The opaque URI is a mapping to a physical address which is exhanged outside the MSRP protocol. This allows topology hiding without re-writing any MSRP messages that flow through a SIP B2BUA, which is a very expensive operation. The opaque URI is a pointer to an exernally conveyed routable URI. This document describes a mechanism to convey the routable URI in the SDP offer/answer exchange used to initiate the MSRP session. The opaque URI is used in the MSRP message headers, while the transport addressing conveyed in SDP is used for the transport layer connections. The basic concept is that instead of indicating the MSRP transport connection information in the MSRP path SDP attribute, and using such in the to-path/from-path MSRP headers, a pseudo-random string is used instead: the MSRP opaque URI. An MSRP client inserts a pseudo-random MSRP opaque URI value in the SDP MSRP path attribute, and uses this value in MSRP messages for its path headers. Actual transport connection information is instead conveyed in the standard SDP connection and media lines. 3. Overview of Operations An MSRP User Agent following this document's mechanism will generate a SIP INVITE for an MSRP-based media session by populating the SDP MacDonald & Kaplan Expires January 8, 2009 [Page 3] Internet-Draft Opaque MSRP Path July 2008 connection line and media line with transport addressing information, as is done for COMEDIA., along with an MSRP opaque URI for the SDP MSRP path attribute. It will also insert the new 'msrp-opaque' option tag into a SIP Require header field. The SIP UAS receiving the INVITE request will see the MSRP URI is an opaque type, due to a new 'opaque' URI parameter defined later in this document. It will then respond with an SDP answer also indicating an MSRP opaque URI, with its actual transport address information in the SDP connection and media lines. Per RFC4975 [RFC4975]. , the UAC will initiate the TCP connection to the UAS, however per this document the TCP connection would use the SDP connection and media lines for addressing info instead of the MSRP URI directly. If another connection model is implemented, such as one following COMEDIA which allows the SIP UAS to initiate the media TCP connection instead, it would still use the SDP connection and media lines instead of the MSRP URI for transport addressing. The MSRP messages generated by the UAC and UAS MUST continue to use the MSRP path attribute opaque URI for the to/from-path MSRP headers. Since the URI is not directly dereferenceable for transport addressing, each UA maintains an internal binding of MSRP opaque-URI to connection transport information. If the TCP connection for MSRP were to go directly from the UAC to the UAS, then clearly one could simply learn the UA addressing on the wire, or by looking at SDP information, and anonymity would not be achieved. It is expected that in typical deployment the media transport information is obfuscated through some other means, such as SBC's or ALG's performing media relay functions, or whatever; but that is beyond the scope of this document. The goal of this document is to provide anonymity for MSRP, not SIP nor SDP. The approach defined in this document does not fit with the MSRP Relay model of RFC 4976, where an MSRP client can use a special intermediary called an "MSRP Relay". Such devices have seen very limited deployment, if any. Instead, most intermediaries are MSRP Application Servers, acting as full MSRP Back-to-Back User Agents, or they are typical SIP intermediate types of devices, such as SBCs and ALGs. One of the goals of this specification is to be able to make MSRP work across such intermediaries. [Note: the MSRP opaque URI model *could* be made to work with MSRP Relays, if the Relays were to know about such URIs in advance - it is TBD whether it is worth specifying how that could/should work] MacDonald & Kaplan Expires January 8, 2009 [Page 4] Internet-Draft Opaque MSRP Path July 2008 4. MSRP Opaque URI 4.1. Opaque URI Parameter Format The opaque URI is an MSRP URI which has an 'opaque' URI parameter as defined later. The opaque URI param is globally unique. If an client wants to use the opaque URI for anonyminity it will use the .invalid domain. For example: path:msrp://msrp.invalid.com:7394/ 2s93u93udj;tcp;opaque=f7jey483rydfhkyerky3. The port has no meaning when the invalid domain is used. This allows backwards compatibility with MSRP implementations that do not support this extension if a valid URI is used. 4.2. Generating an Opaque Uri Parameter TODO: determine generation scheme and encoding 4.3. MSRP URI Parameter This document defines a new MSRP URI parameter: "opaque". The opaque URI parameter is a token which is globally unique and can be used to map back to a TCP(or other protocol) connection. The ABNF for this parameter, following RFC4975 [RFC4975], is as follows: URI-parameter = opaque-param / (token ["=" token]) opaque-param = "opaque" EQUAL token 5. SIP Option Tag This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC3261 [RFC3261]. Name: msrp-opaque Description: This option-tag is used to identify UAs which support the mechanism defined in this document. SIP User Agents MUST include a Requires header field with the "msrp- opaque" option-tag when using an invalid URI with an opaque parameter in an SDP offer or answer in a SIP message. SIP User Agents SHOULD include a Supported header field with an the "msrp-opaque" option-tag if they support this specification but still wish to generate a valid URI in the SDP. This allows the UAS to reject the request with a Require header field containing "msrp- opaque" to indicate the UAS requires the UAC to use an opaque URI; MacDonald & Kaplan Expires January 8, 2009 [Page 5] Internet-Draft Opaque MSRP Path July 2008 and this allows for backwards compatibility as described in the next section. 6. Backwards Compatibility with RFC 4975 and 4976 When a UAC initiates an MSRP session, it may need to interoperate with legacy devices based on RFC 4975 and 4976. This can be accomplished with the opaque URI mechanism in the following way, as long as the UAC does not itself require anonymization of its URI: the UAC generates a legacy RFC 4975 MSRP URI, but adds an 'opaque' parameter to the end of it, and sets the SDP connection and media lines to be the real transport addresses as well, and adds a Supported option tag of "msrp-opaque". If the answering UAS only supports RFC 4975 and/or 4976, it will ignore the opaque parameter and Supported option tag, and respond and act as per RFC 4975. If the UAS supports the opaque mechanism, and wishes to anonymize its MSRP URI, it responds with an invalid URI with an opaque parameter and a SIP Require header field with the "msrp-opaque" option tag. 7. Example Scenario In the following example, Alice invites Bob to an MSRP session. Alice does not wish her IP address to be known, as it conveys information about her location and might make her system vulnerable to attacks. Similarily, the Atlanta network has a policy of not exposing such details about their network or their users. In this case Alice and Bob are both at atlanta.example.com Alice Atlanta Network Bob | | | |------INVITE------->| 1 | | |------INVITE------>| 2 | |<------200---------| 3 |<------200----------| 4 | |-------ACK--------->| | | |-------ACK-------->| | | | Message 1 is an INVITE where msrp-opaque is required and an opaque MSRP URI is used in the SDP. MacDonald & Kaplan Expires January 8, 2009 [Page 6] Internet-Draft Opaque MSRP Path July 2008 INVITE sip:bob@atlanta.example.com SIP/2.0 To: From: ;tag=786 Call-ID: 3413an89KU Requires: msrp-opaque Content-Type: application/sdp - c=IN IP4 192.168.0.100 m=message 12454 TCP/MSRP * a=path:msrp://msrp.invalid.com:7394/jshA7weztas;tcp;opaque=f7jey483rydfhkyerky3 The connection c-line of the SDP identifies Alice's actual transport address for the MSRP connection, and the media m-line port portion identifies the TCP port; as opposed to the msrp path attribute as defined in RFC4975 [RFC4975]. They may be changed by intermediate nodes to point to an address:port on a TCP relay service in the Atlanta network. c=IN IP4 border.altanta.example.com m=message 22454 TCP/MSRP * a=path:msrp://msrp.invalid.com:7394/jshA7weztas;tcp;opaque=f7jey483rydfhkyerky3 The relevant portion on the SDP from Message 3. For simplicity, Bob's UA has been given a publicly reachable IP address. c=IN IP4 bob.altanta.example.com m=message 34313 TCP/MSRP * a=path:msrp://msrp.invalid.com:7394/kjhd37s2s20w2a;tcp;opaque=a6ghr7yv6egw33r Which is re-written to point to the border element. c=IN IP4 border.altanta.example.com m=message 27784 TCP/MSRP * a=path:msrp://msrp.invalid.com:7394/kjhd37s2s20w2a;tcp;opaque=a6ghr7yv6egw33r After this exchange is complete Alice will form a connection to the border.atlanta.example.com which will in turn connect to Bob's UA. border.atlanta.example.com acts as a simple TCP relay between Bob and Alice until the TCP connection is torn down by either party. While some of this functionality can be achieved with the MSRP relay specification, or by using TURN-TCP, this approach has it's own advantages and disadvantages. Advantages: The opaque-uri can provide topology hiding. This can also be provided by TURN-TCP, but will end up w/ two TURN allocations MacDonald & Kaplan Expires January 8, 2009 [Page 7] Internet-Draft Opaque MSRP Path July 2008 being used. At the media level, the opaque-uri approach only requires a TCP relay which has no knowledge of MSRP. It is a small change for endpoints which already support MSRP. Disadvantages: Until the TCP relay has connected to the second peer(Bob), any MSRP requests from Alice must be rate-limited or cached. In practice, rate limiting seems to work well; if the connection to Bob fails, the connection to Alice would be torn down. This does not provide the same level of error reporting as MSRP-Relay. Mapping rules must be conveyed from the signal-plane(SIP/SDP) to the Media Plane(TCP relay) 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007. Authors' Addresses Derek C. MacDonald CounterPath Solutions, Inc. Suite 300, One Bentall Centre, 505 Burrard St Vancouver, BC V7X1M3 Canada Phone: +1-604-320-3344 Email: derek@counterpath.com MacDonald & Kaplan Expires January 8, 2009 [Page 8] Internet-Draft Opaque MSRP Path July 2008 Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA Phone: Fax: Email: hkaplan@acmepacket.com URI: MacDonald & Kaplan Expires January 8, 2009 [Page 9] Internet-Draft Opaque MSRP Path July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. MacDonald & Kaplan Expires January 8, 2009 [Page 10]