Opaque MSRP Path Uri

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 MSRP relays will not be able to route from opaque MSRP uris.

A requirment network architectures is to hide the core architecture of the 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 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. This specification defines an opaque 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 all MSRP messages that flow through a boundary, 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 an MSRP URI which has a domain name in the .invalid TLD. A globally unique identifier is generated and encoded as a URI in the .invalid tld. For example: path:msrp://f7jey483rydfhkyerky3.invalid.com:7394/2s93u93udj;tcp. The opaque URI pointer is the first portion of the URI before invalid.com: f7jey483rydfhkyerky3. The port is arbitrary.

Should there be a fixed value for the port?

In the following example invites Bob to an MSRP session. Alice does not wish her IP address to be known(still working on that restraining order against Bob) as it conveys information about her location and might make her system vulnerable to attacks. Similarily, the Atlanata network has a policy of exposing minimal details about their network. In this case Alice and Bob are both at atlanta.example.com

| 1 | | |------INVITE------>| 2 | |<------200---------| 3 |<------200----------| 4 | |-------ACK--------->| | | |-------ACK-------->| | | | ]]> Message 1 is an INVITE where msrp-opaque is required and an opaque MSRP usi is used in the SDP.

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=accept-types:text/plain a=path:msrp://f7jey483rydfhkyerky3.invalid.com:7394/jshA7weztas;tcp a=opaque ]]> The C line of the SDP will be changed to point to a port on an TCP relay service in the Atlanta network.

The relevant portion on the SDP from Message 3. For simplicity, Bob's UA has been given a publicly reachable IP address.

Which is re-written to point to the border element.

After this exchange is complete Alice will form a connection to the border.atlanta.com which will in turn connect to Bob's UA. border.atlanata.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 provides topology hiding. This can also be provided by TURN-TCP, but will end up w/ two TURN allocations 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)

The identifying portion of the opaque uri is the portion up to .invalid.com. This portion should be cryptographically unique and MUST be encoded so it obeys rfc3986. Opaque URIs do not modify the grammar of rfc4975. TODO: determine generation scheme and encoding

The SDP attribute "a=opaque" MUST appear to identify an opaque URI whenever one is used.

Endpoints MUST include an Requires header with an option tag value of "msrp-opaque" when using an opaque uri as an offer or answer in a SIP message. OPEN ISSUE: Since this mecahnism is largely for intermediate elements, is Proxy-Require a better fit?