| TOC |
|
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.
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 to support those cases.
1.
Introduction
2.
Problem Statement
2.1.
Unknown Aliases
2.2.
Unknown GRUU
2.3.
Limited Use Addresses
2.4.
Sub-Addressing
2.5.
Service Invocation
3.
Architectural Roots of the Problem
4.
Solution Overview
5.
Detailed Semantics
5.1.
Proxy Behavior
5.2.
UA Behavior
6.
Syntax
7.
Security Considerations
8.
References
8.1.
Normative References
8.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
A key part of the behavior of proxy servers and B2BUA in the Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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 (Problem Statement) describes the problems with this mechanism. Section 3 (Architectural Roots of the Problem) analyzes the architectural issues which drive these problems. Section 4 (Solution Overview) overviews a mechanism to solve this problem by extending the History-Info header field. Section 5 (Detailed Semantics) describes detailed procedures for user agents and proxies.
| TOC |
Several problems arise from the practice of rewriting the request URI.
| TOC |
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.
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.
| TOC |
A variation on the problem in Section 2.1 (Unknown Aliases) occurs with Globally Routable User Agent URI (GRUU) [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.). 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.
| TOC |
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] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.). 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 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.
| TOC |
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.
| TOC |
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] (Campbell, B. and R. Sparks, “Control of Service Context using SIP Request-URI,” April 2001.), control of network announcements and IVR with SIP URI [RFC4240] (Burger, E., Van Dyke, J., and A. Spitzer, “Basic Network Media Services with SIP,” December 2005.), and control of voicemail access with SIP URI [RFC4458] (Jennings, C., Audet, F., and J. Elwell, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.).
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.
| TOC |
There is a common theme across all of the problems in Section 2 (Problem Statement), 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] (Jennings, C., “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” June 2009.), 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] (Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, “SIP: Session Initiation Protocol,” March 1999.) 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.
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".
| TOC |
The History-Info header field, defined in [RFC4244] (Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.), 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 (Target URI Example). 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 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 |
| TOC |
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.
| TOC |
A proxy compliant to this specification SHOULD add a History-Info header field value to a request under the following conditions:
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.
| TOC |
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 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.
| TOC |
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"
| TOC |
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.
| TOC |
| TOC |
| [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 (TXT). |
| [RFC4244] | Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” RFC 4244, November 2005 (TXT). |
| TOC |
| TOC |
| Jonathan Rosenberg | |
| Cisco | |
| Edison, NJ | |
| US | |
| Email: | jdrosen@cisco.com |
| URI: | http://www.jdrosen.net |
| TOC |
Copyright © 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.
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.