[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
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: <sip:bob@atlnata.example.com>
        From: <sip:alice@atlanta.example.com>;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]