Internet DRAFT - draft-macdonald-simple-msrp-opaque-path
draft-macdonald-simple-msrp-opaque-path
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]
