SIPPING J. Rosenberg
Internet-Draft Cisco
Intended status: Informational October 27, 2008
Expires: April 30, 2009
Delivery of Request-URI Targets to User Agents
draft-rosenberg-sip-target-uri-delivery-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 April 30, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
When a Session Initiation Protocol (SIP) proxy receives a request
targeted at a URI identifying a user or resource it is responsible
for, the proxy translates the URI to a registered contact URI of an
agent representing that user or resource. In the process, the
original URI is removed from the request. Numerous use cases have
arisen which require this information to be delivered to the user
agent. This document describes these use cases and defines an
extension to the History-Info header field which allows it to be used
Rosenberg Expires April 30, 2009 [Page 1]
Internet-Draft Target URI October 2008
to support those cases.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 3
2.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 4
2.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 5
3. Architectural Roots of the Problem . . . . . . . . . . . . . . 6
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7
5. Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 8
5.2. UA Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Rosenberg Expires April 30, 2009 [Page 2]
Internet-Draft Target URI October 2008
1. Introduction
A key part of the behavior of proxy servers and B2BUA in the Session
Initiation Protocol (SIP) [RFC3261] is that they rewrite the Request-
URI of requests as the request moves from the User Agent Client (UAC)
to the User Agent Server (UAS). This is particularly true for
requests outside of a dialog; requests within a dialog have their
path dictated primarily by the Route header fields established by the
Record-Routes when the dialog was initiated.
The most basic instance of this behavior is the processing executed
by the "home proxy" within a domain. The home proxy is the proxy
server within a domain which accesses the location information
generated by REGISTER messages, and uses it to forward a request
towards a UAC. Based on the rules in RFC 3261, when a home proxy
receives a SIP request, it looks up the Request-URI in the location
database, and translates it to the contact(s) that were registered by
the UA. This new contact URI replaces the existing Request URI, and
causes the request to be forwarded towards the target UA.
Consequently, the original contents of the Request URI are lost.
Over the years, this practice of rewriting the Request-URI has proven
problematic. Section 2 describes the problems with this mechanism.
Section 3 analyzes the architectural issues which drive these
problems. Section 4 overviews a mechanism to solve this problem by
extending the History-Info header field. Section 5 describes
detailed procedures for user agents and proxies.
2. Problem Statement
Several problems arise from the practice of rewriting the request
URI.
2.1. Unknown Aliases
SIP user agents are associated with an address-of-record (AOR). It
is possible for a single UA to actually have multiple AOR associated
with it. One common usage for this is aliases. For example, a user
might have an AOR of sip:john@example.com but also have the AORs
sip:john.smith@example.com and sip:jsmith@example.com. Rather than
registering against each of these AORs individually, the user would
register against just one of them, and the home proxy would
automatically accept incoming calls for any of the aliases, treating
them identically and ultimately forwarding them towards the UA. This
is common practice in the Internet Multimedia Subsystem (IMS), where
it is called implicit registrations and each alias is called a public
identity.
Rosenberg Expires April 30, 2009 [Page 3]
Internet-Draft Target URI October 2008
It is a common requirement for a UAS, on receipt of a call, to know
which of its aliases was used to reach it. This knowledge can be
used to choose ringtones to play, determine call treatment, and so
on. For example, a user might give out one alias to friends and
family only, resulting in a special ring that alerts the user to the
importance of the call.
However, based on the procedures in RFC 3261, when an incoming call
hits the home proxy, the request URI (which contains the alias) is
rewritten to the registered contact(s). Consequently, the alias that
was used is lost, and cannot be known to the UAS.
2.2. Unknown GRUU
A variation on the problem in Section 2.1 occurs with Globally
Routable User Agent URI (GRUU) [I-D.ietf-sip-gruu]. A GRUU is a URI
assigned to a UA instance which has many of the same properties as
the AOR, but causes requests to be routed only to that specific
instance. It is desirable for a UA to know whether it was reached
because a correspondent sent a request to its GRUU or to its AOR.
This can be used to drive differing authorization policies on whether
the request should be accepted or rejected, for example. However,
like the AOR itself, the GRUU is lost in translation at the home
proxy. Thus, the UAS cannot know whether it was contacted via the
GRUU or its AOR.
2.3. Limited Use Addresses
A limited use address is an SIP URI that is minted on-demand, and
passed out to a small number (usually one) remote correspondent.
Incoming calls targeted to that limited use address are accepted as
long as the UA still desires communications from the remote target.
Should they no longer wish to be bothered by that remote
correspondent, the URI is invalidated so that future requests
targeted to it are rejected.
Limited use addresses are used in battling voice spam [RFC5039]. The
easiest way to provide them would be for a UA to be able to take its
AOR, and "mint" a limited use address by appending additional
parameters to the URI. It could then give out the URI to a
particular correspondent, and remember that URI locally. When an
incoming call arrives, the UAS would examine the parameter in the URI
and determine whether or not the call should be accepted.
Alternatively, the UA could push authorization rules into the
network, so that it need not even see incoming requests that are to
be rejected.
This approach, especially when executed on the UA, requires that
Rosenberg Expires April 30, 2009 [Page 4]
Internet-Draft Target URI October 2008
parameters attached to the AOR, but not used by the home proxy in
processing the request, will survive the translation at the home
proxy and be presented to the UA. This will not be the case with the
logic in RFC 3261, since the Request-URI is replaced by the
registered contact, and any such parameters are lost.
2.4. Sub-Addressing
Sub-Addressing is very similar to limited use addresses. Sub-
addresses are addresses within a subdomain that are multiplexed into
a single address within a parent domain. The concept is best
illustrated by example. Consider a VoIP service provided to
consumers. A consumer obtains a single address from its provider,
say sip:family@example.com. However, Joe is the patriarch of a
family with four members, and would like to be able to have a
separate identifier for each member of his family. One way to do
that, without requiring Joe to purchase new addresses for each member
from the provider, is for Joe to mint additional URI by adding a
parameter to the AOR. For example, his wife Judy with have the URI
sip:family@example.com;member=judy, and Joe himself would have the
URI sip:family@example.com;member=joe. The SIP server provider would
receive requests to these URI, and ignoring the unknown parameters
(as required by RFC 3261) route the request to the registered
contact, which corresponds to a SIP server in Joes home. That
server, in turn, can examine the URI parameters and determine which
phone in the home to route the call to.
This feature is not specific to VoIP, and has existing in Integrated
Services Digital Networking (ISDN) for some time. It is particularly
useful for small enterprises, in addition to families. It is also
similar in spirit (though not mechanism) to the ubiquitous home
routers used by consumers, which allow multiple computers in the home
to "hide" behind the single IP address provided by the service
provider, by using the TCP and UDP port as a sub-address.
The sub-addressing feature is not currently feasible in SIP because
of the fact that any SIP URI parameter used to convey the sub-address
would be lost at the home proxy, due to the fact that the Request-URI
is rewritten there.
2.5. Service Invocation
Several SIP specifications have been developed which make use of
complex URIs to address services within the network rather than
subscribers. The URIs are complex because they contain numerous
parameters that control the behavior of the service. Examples of
this include the specification which first introduced the concept,
RFC 3087 [RFC3087], control of network announcements and IVR with SIP
Rosenberg Expires April 30, 2009 [Page 5]
Internet-Draft Target URI October 2008
URI [RFC4240], and control of voicemail access with SIP URI
[RFC4458].
A common problem with all of these mechanisms is that once a proxy
has decided to rewrite the Request-URI to point to the service, it
cannot be sure that the Request-URI will not be destroyed by a
downstream proxy which decides to forward the request in some way,
and does so by rewriting the Request-URI.
3. Architectural Roots of the Problem
There is a common theme across all of the problems in Section 2, and
this theme is the confounding of names, routes, and addresses.
A name is a moniker for an entity which refers to it in a way which
reveals nothing about where it is in a network. On the Internet,
names are ideally provided through Universal Resource Names (URNs).
An address is an identifier for an entity which describes it by its
location on the network. In SIP, the SIP URI itself is a form of
address because the host part of the URI, the only mandatory part of
the URI besides the scheme itself, indicates the location of a SIP
server that can be used to handle the request. Finally, a route is a
sequence of SIP entities (including the UA itself!) which are
traversed in order to forward a request to an address or name.
SIP, unfortunately, uses the Request-URI as a mechanism for routing
of the request in addition to using it as the mechanism for
identifying the name or address to which the request was targeted. A
home proxy rewrites the Request-URI because that rewriting is the
vehicle by which the request is forwarded to the target of the
request. However, this rewritten URI (the contact from the
register), is not in any way a meaningful name or address for the UA.
Indeed, with specifications like SIP outbound
[I-D.ietf-sip-outbound], even the IP address within the registered
contact is meaningless since the flow on which the REGISTER is sent
is used rather than the IP address. Consequently, the home proxy is
fundamentally replacing the *address* in the Request-URI with a
*route* to reach that UA. This architectural mistake is the cause of
the problems described above.
Interestingly, this same mistake was present in RFC 2543 [RFC2543]
for the handling of mid-dialog requests. It was fixed through the
loose routing mechanism in RFC 3261, which used Route header fields
to identify each hop to visit for a mid-dialog request, and separated
this from the Request-URI, which identified the ultimate target of
the request (the remote UA), and remained unmodified in the
processing of the request.
Rosenberg Expires April 30, 2009 [Page 6]
Internet-Draft Target URI October 2008
Unfortunately, application of this same technique to address the
problem at hand cannot be done in a backwards compatible manner.
Consequently, some other means is needed to clearly identify which
URIs are addresses, and which are routes. To avoid confusion, we
refer to a SIP URI that is an address for a user or resource as a
"target" and a SIP URI that is a hop for reaching that user as a
"hop".
4. Solution Overview
The History-Info header field, defined in [RFC4244], defines a
mechanism by which an enumeration of the URIs traversed can be passed
to both the UAC and UAS. History-Info was designed to provide a
general purpose mechanism which can support the needs of many
applications, including diagnostics and traditional telephony
features like voicemail. Were a home proxy to implement History-
Info, it would provide a means for that proxy to deliver the target
URI to the UAS.
Unfortunately, History-Info makes no distinction between URIs that
are targets and URIs that are hops. Consequently, if there were
additional proxies downstream of the home proxy which modified the
Request-URI in any way, the UA would have no way to know which URI in
the list of History-Info values was actually the target. To remedy
that, this document defines an extension to the History-Info header
field which indicates whether the URI is a target or not.
When a home proxy receives a request for a user or resource for which
it has a registration, the proxy adds two History-Info header field
values. The first is the incoming request URI. Since the Request-
URI identifies a user or resource for which it has a registration,
the Request-URI is an AOR and thus an address for the user. The
proxy adds a History-Info header field parameter, "target", which
indicates this. Next, the proxy inserts the contact URI it used in
the outgoing Request-URI. No target parameter is included in this
History-Info value.
For a UA to determine the URI target, it need only walk backwards
through the list of HI values, and take the first one containing the
"target" parameter.
For example, consider the architecture in Figure 1. In the example
user A calls user B. User B is in example.com. The call from A to B
passes through A's outbound proxy, their home proxy, B's home proxy,
and B's outbound proxy, prior to reaching B. B's home proxy, H-B,
performs the translation of the R-URI to the registered contact based
on the registration database. Consequently, it adds two History-Info
Rosenberg Expires April 30, 2009 [Page 7]
Internet-Draft Target URI October 2008
header fields, the first of which represents the incoming R-URI and
includes the "target" parameter.
+-------+ +-------+ +-------+ +-------+
//--\\ | | | | | | | | //--\\
| A |--- | OB-A |----| H-A |---| H-B |---| OB-B |--| B |
| | | | | | | | | | | |
\\--// +-------+ +-------+ +-------+ +-------+ \\--//
INVITE
sip:B@example.com
------------>
INVITE
sip:B@example.com
------------>
INVITE
sip:B@example.com
------------>
INVITE
sip:B@example.com
HI: <sip:B@example.com>index=1;target,
<sip:B@1.2.3.4>;index=1.1
------------>
Figure 1: Target URI Example
5. Detailed Semantics
The "target" parameter in the History-Info header field indicates
that the URI that it parameterizes was subject to a lookup in a
location service created through the registration process of the UA.
Furthermore, if that URI had an 'index' of N, the URIs with indices
N.M for all M, are the registered contacts to that URI.
5.1. Proxy Behavior
A proxy compliant to this specification SHOULD add a History-Info
header field value to a request under the following conditions:
o The proxy is responsible for the domain in AOR in the Request-URI
o The proxy will be translating the contents of the Request-URI to
one or more registered contacts based on a location database
Rosenberg Expires April 30, 2009 [Page 8]
Internet-Draft Target URI October 2008
populated through REGISTER requests from user agents.
o The R-URI exists in the location database.
The proxy SHOULD populate the History-Info header field regardless of
whether there is a Supported header field with value 'histinfo'. If
the incoming request already contains a History-Info header field,
and the last value of that header field is identical to the Request-
URI of the received request, the proxy MUST add a "target" attribute
to that History-Info value. If the request did not contain a
History-Info header field, or if it did, but the last value is not
identical to the Request-URI of the received request, the proxy MUST
add another History-Info header field value. The URI MUST be equal
to the incoming Request-URI, and MUST contain a "target" attribute.
The index is set as defined in RFC 4244.
Once the proxy has translated the Request-URI into a registered
contact, it MUST add an additional History-Info header field value
containing the Contact URI for each request to be forwarded. The
"target" attribute MUST NOT be present. The index is set as defined
in RFC 4244.
Since the principal purpose of the "target" parameter is to indicate,
to a UAS, the target URI by which it was reached, there is no need
for the History-Info header field values to be passed outside of the
domain which inserted them. There may be other applications of
History-Info which require it, however.
If the proxy is actually redirecting and not forwarding the request,
it SHOULD include a History-Info URI in the response for the target.
That URI, if present, MUST contain the 'target' attribute. It SHOULD
NOT add a History-Info URI for the registered contact; the previous
hop proxy will do that. Note that, this rule violates a SHOULD-
strength rule in Section 4.3.4 of RFC 4244. That section indicates
that redirections "SHOULD NOT" contain any new History-Info header
fields, as those will be added by the upstream server. For this
application however, only the downstream server knows that the R-URI
was a target, and thus the History-Info header field and the "target"
attribute must be added by the downstream server.
5.2. UA Behavior
A UAS receiving a request, and wishing to determine the original
target dialog, takes the values in the History-Info header field, and
traverses through them in reverse order. Note that, the value of the
"index" attribute is not relevant; the traversal is in order of the
header fields values themselves. The UAS finds the first header
field value containing the "target" parameter. If such a value does
Rosenberg Expires April 30, 2009 [Page 9]
Internet-Draft Target URI October 2008
not exist, the target URI cannot be reliably determined. If it does
exist, the URI is examined. If the domain of the URI matches the
domain of the UA, based on the UA's configured awareness of its own
domain, that URI is the target URI. If the domains do not match, the
target URI cannot be reliably determined. This domain check is
present to handle cases where a request is forwarded through two
separate domains, and the domain of the actual UAS didn't support
this specification, but the previous domain did.
Beyond this, there is no special UA processing associated with the
"target" parameter.
6. Syntax
This specification extends the syntax of hi-param in Section 4.1 of
RFC 4244:
hi-param = hi-index / hi-target / hi-extension
hi-target = "target"
7. Security Considerations
The "target" parameter indicates that a URI was subject to
translation by a home proxy, and consequently, acts as an explicit
indicator that a particular URI was an AOR for a user. This might be
useful for attackers wishing to farm requests for targettable URIs
for purposes of spamming. Of course, such attackers can utilize URIs
in History-Info even if they lack the "target" attribute, so "target"
does not really exacerbate this. Nonetheless, since the princpal
application of the "target" parameter is delivery of a URI to a UAS
within the same domain, History-Info values inserted solely for this
purpose SHOULD be removed at the domain boundary.
8. References
8.1. Normative References
[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.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Rosenberg Expires April 30, 2009 [Page 10]
Internet-Draft Target URI October 2008
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.
8.2. Informative References
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
using SIP Request-URI", RFC 3087, April 2001.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires April 30, 2009 [Page 11]
Internet-Draft Target URI October 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosenberg Expires April 30, 2009 [Page 12]