DISPATCH Working Group H. Kaplan Internet Draft Acme Packet Intended status: Informational Expires: April 18, 2011 October 18, 2010 Problems with the SIP Globally Routable User Agent URIs (GRUUs) draft-kaplan-dispatch-gruu-problematic-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 18, 2011. Copyright and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Kaplan Expires April 18, 2011 [Page 1] Internet-Draft Problems with SIP GRUUs October 2010 Abstract This document identifies some issues discovered in deployments of the SIP GRUU mechanism defined in [RFC5627], cases in which GRUUs may be harmful, and considerations for B2BUAs handling GRUUs. Table of Contents 1. Introduction ..................................................2 2. Terminology ...................................................3 3. Problems with Access Proxies ..................................3 4. Problems with B2BUAs ..........................................5 5. Problems with Global Reachability .............................7 5.1. Access-Restricted Domains ................................8 5.2. Routing-Restricted Domains ...............................8 5.3. IPv6 Reachability ........................................9 6. Alternatives to GRUU ..........................................9 7. Conclusion ...................................................10 8. Security Considerations ......................................11 9. IANA Considerations ..........................................11 10. References ..................................................11 10.1. Informative References .................................11 Author's Address.................................................11 1. Introduction The SIP GRUU mechanism defined in [RFC5627] is intended to provide a SIP URI which can be used to reach a specific User Agent (UA) from anywhere on the Internet. A UA can obtain a GRUU through the registration process, whereby the Registrar creates the GRUU and passes it to the UA, and the UA can use that GRUU as a Contact URI in subsequent non-REGISTER SIP requests, and other SIP entities can use the GRUU to reach that specific UA in out-of-dialog requests. Alternatively, a UA that is publicly reachable on the Internet can create a self-made GRUU as described in [RFC5627]. GRUUs are URIs with specific properties: they are intended to be globally routable, meaning they could be used by any SIP device on the Internet as the target of a request to reach the specific UA assigned the GRUU, and they are valid for at least the duration of a registration in the case of temp-GRUUs, or longer in the case of public-GRUUs. One use-case often cited for needing GRUUs is for call-transfer scenarios, whereby the transferor REFERs a transferee to a transfer target by giving it the GRUU of the transfer target in the Refer-To header value, and may also use a GRUU of the transferee in the Request-URI of an out-of-dialog REFER. Because a SIP AoR may Kaplan Expires - April 2011 [Page 2] Internet-Draft Problems with SIP GRUUs October 2010 represent multiple UAs, they cannot be used for some call-transfer cases, and Contact URIs are used instead; GRUUs would be used in such cases because they are globally routable forms of Contact URIs. It is commonly assumed that GRUUs are necessary for such call- transfer scenarios to function, although in practice that has not been the case. GRUUs have not seen widespread adoption yet, but they have appeared, and are even used frequently by at least one vendor. Initial deployments have uncovered some problems with using GRUUs, which this document attempts to capture. The MARTINI Working Group has also considered making GRUUs a requirement for SIP Trunking, in order to make call-transfer scenarios work, which this document attempts to explain GRUU is neither necessary nor sufficient for. Furthermore, there is confusion and debate with regards to what a B2BUA should do with GRUU Contact-URIs, which this document tries to provide some background considerations for. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". GRUU: Globally Routable User Agent URI, as defined in [RFC5627]. UA: SIP User Agent. Out-of-dialog request: a SIP request which is not sent in a dialog, but may form a dialog. For example an initial INVITE, SUBSCRIBE, PUBLISH, MESSAGE, or REFER request; essentially, a request with no To-tag. 3. Problems with Access Proxies A common deployment model for SIP Service Providers (SSPs) and Enterprises with remote workers, is to deploy Proxies or SBCs between registering UAs or IP-PBXs and the authoritative Registrar(s). For sake of brevity, this document will refer to any such devices as "Access Proxies". Such Access Proxies are session stateful, may record-route or act as B2BUAs, and typically have authorization or admission policies, but do not directly query the Registrar database for AoR-to-Contact binding resolution information. If the Access Proxy receives a dialog-forming SIP Request from a registered UA, then upstream mid-dialog requests to that UA will Kaplan Expires - April 2011 [Page 3] Internet-Draft Problems with SIP GRUUs October 2010 cause the Access Proxy to follow [RFC3261] and route them to the Request-URI of the mid-dialog request. If that Request-URI is the initial Contact-URI of the dialog-forming request, and it was a GRUU, then the Access Proxy may fail to route it to the UA because the GRUU identifies the Access Proxy's own domain rather than the UA's address, and thus causes an unexpected spiral. For example, suppose Alice is a registered UA of domain "example.com", with a public GRUU of "sip:alice@example.com;gr=foo". Alice sends Bob an INVITE request with her GRUU as the Contact-URI of the INVITE, through her Access Proxy. The Access Proxy inserts a Record-Route of "sip:aproxy.example.com". The INVITE establishes a dialog, with Bob storing a route set of "sip:aproxy.example.com" and a remote target of "sip:alice@example.com;gr=foo". If Bob generates a BYE to end the dialog, he will set the Request-URI of the BYE to "sip:alice@example.com;gr=foo", with a Route header of "sip:aproxy.example.com". The Access Proxy receives the request, pops the Route header, and will try to route using "sip:alice@example.com;gr=foo", which will cause a loop. The intention of [RFC5627] is for originating and terminating Proxies to record-route in many cases, as described in section 6.2 of [RFC5627]. In particular, if the Access Proxy inserts a Record- Route header as described above, and it passes through an authoritative Proxy-Registrar, then the authoritative Proxy- Registrar would also insert a Record-Route, and per the rules of [RFC3261] and section 6.1 of [RFC5627], the authoritative Proxy- Registrar would replace the GRUU in the Request-URI of the BYE to be the real registered Contact URI. In such a case the Access Proxy would receive the real registered Contact URI as the Request-URI, and all would be good. But what if the Access Proxy did not route the request through an authoritative Registrar-Proxy, or what if the Access Proxy were a B2BUA instead? This type of scenario actually occurred in initial deployments. In the initial deployment case, the Access Proxy was not inserting a Record-Route of itself, but was instead a B2BUA inserting a new Contact-URI of itself, which it mapped back to the original (GRUU) Contact-URI. The authoritative Registrar-Proxy never sees the GRUU Contact nor a Record-Route. Therefore, in the initial deployment, the B2BUA received its own Contact URI in the Request-URI of the BYE, mapped it to "sip:alice@example.com;gr=foo", and failed to resolve that because it did not have any special/new handling for GRUUs. Even if the Access Proxy had been Record-Routing, however, it would have failed in certain cases. A request from Alice to Bob need not go to any Proxy with access to the Registration database. For example, Access Proxies can typically route calls for Emergency Kaplan Expires - April 2011 [Page 4] Internet-Draft Problems with SIP GRUUs October 2010 numbers directly to gateways/peers, or Bob could simply be a conference server known to the Access Proxy to which it can route directly. In such cases, no authoritative Registrar-Proxy would be in the path to perform the mid-dialog Request-URI rewriting. Neither [RFC3261] nor [RFC5627] require all requests from a UA to route through that UA's authoritative Registrar-Proxy, and yet that is the only way a GRUU model could work as currently defined. The obvious solution is for the originating UA (Alice) to insert a Record-Route of her actual/real registered Contact-URI in the dialog-forming request. Arguably this should have been the model from the beginning for [RFC5627]. An uglier but sometimes easier to deploy solution is for the Access Proxy to insert a Record-Route in the dialog-forming request on the originating UA's (Alice's) behalf, using the Via information as a pseudo-Contact. This latter method has issues if the originating UA is not directly communicating with the Access Proxy (i.e., if there is another Proxy in-between). Access Proxies which are B2BUAs with registration caching (e.g., SBC's) can insert a Record-Route of the matched registered contact, instead, to avoid such issues. 4. Problems with B2BUAs It is quite common for SIP requests to be processed by B2BUAs on their way to the "final" UA destinations. There are many types of B2BUAs which may be in the path: IP-PBXs, Feature Servers, Application Servers, Session Border Controllers, Transcoding Servers, Call-Continuity Servers, etc. The degree to which specific elements act as SIP Proxies vs. full B2BUAs varies, but it is quite common for such servers to replace the received Contact URI of requests with their own URI. In fact, arguably they *have to* replace the Contact, because by definition they are the UAC of the request they create from a received request on their UAS side. From a logical perspective, the SIP request they received as a UAS ends at them, and a brand new one is generated by them on their UAC side. In the extreme case, a B2BUA may be considered the logical equivalent of two SIP-PSTN gateways connected to each other with a PRI trunk. Because B2BUAs replace the Contact URI of forwarded requests, the final SIP UAS will not receive the GRUU of the original UAC, and may not receive a GRUU at all. The Contact URI it receives will be the URI of the last B2BUA crossed before the request reached the UAS, which may not be a GRUU nor have GRUU properties. In particular, the Contact URI may contain an IP Address or hostname which is not reachable from everywhere on the Internet, and/or it may only be usable for the duration of the dialog its request created. Kaplan Expires - April 2011 [Page 5] Internet-Draft Problems with SIP GRUUs October 2010 Attempts have been made to resolve this by having B2BUAs not change the Contact URI if it is a GRUU (i.e., has a 'gr' param). The rationale was that since a GRUU identifies a globally routable URI, it would be more likely to succeed for out-of-dialog requests than a URI of the B2BUA that would be specific to the B2BUA's interfaces. However passing GRUUs through a B2BUA can only be done in very specific conditions, and often with unforeseen consequences. Since any future out-of-dialog requests may use the GRUU as their target, the B2BUA cannot expect to receive such requests if the GRUU is not its own URI. Although Record-Routing will keep in-dialog requests reaching the B2BUA, one of the main use-cases of GRUUs is for call- transfer scenarios using out-of-dialog requests (REFER and INVITE with [RFC3891] Replaces header), and there is no guarantee such out- of-dialog requests will go through the same B2BUA which processed the original dialog. In particular, if the B2BUA changed the Call-ID or tags of the original dialog, as many do, then an out-of-dialog REFER or INVITE with Replaces header won't work if it reaches the UA without passing through the same B2BUA, because the dialog identifiers of the Replaces won't be fixed by the B2BUA to match what the UA expects. If the B2BUA performs "REFER termination", whereby it processes the REFER on behalf of the UA instead of forwarding it on, then passing on the GRUU of the UA won't always work. If the B2BUA performs IPv4-IPv6 interworking, SIP to/from SIP-I/SIP-T interworking, PRACK to/from non-PRACK interworking, transport layer-type interworking, transcoding, or possibly other forms of interworking, then passing on the GRUU may not work unless the same type of interworking function is guaranteed to be in the path for all requests to that GRUU. See later sections of this document for other cases in which a B2BUA passing on the GRUU won't work. Fundamentally, it is not logical for most B2BUAs to "pass on" a GRUU. The functions they perform are typically on behalf of the UA, as if the functions were in the UA to begin with, and thus they represent a logical "interface" of that UA and the Contact URI needs to identify that specific "interface". Furthermore, from a SIP context perspective, the request ended at the B2BUA, and a new one began - one belonging to the B2BUA - and generating a new request using another device's Contact URI is bound to fail. One option is for the B2UA to generate a self-made GRUU of its own, which it can map to the Contact URI it received. Unfortunately, by definition such a GRUU's de-referenced B2BUA must be publicly reachable on the public Internet, by *any device that receives it*, on both IPv4 and IPv6. Such is almost never the case, cannot be known in advance, and may cause more issues than it solves. Specifically, it may cause more issues if a downstream B2BUA Kaplan Expires - April 2011 [Page 6] Internet-Draft Problems with SIP GRUUs October 2010 attempts to pass through the GRUU Contact when it would have otherwise used its own Contact URI. (see later sections for additional issues) Instead, a logically similar model has been successfully deployed using "Global Contacts", which are Contact URIs having the properties of a GRUU, but not being a GRUU in syntax (i.e., without a 'gr' param, and not indicating an AoR). This has the benefit that downstream B2BUAs/UAs will not treat the Contact as a special GRUU case. Global Contacts are not always valid after their dialog is terminated, but it remains to be seen if this will cause problems in the future. Currently the main use-case for GRUU-like properties is for call-transfer scenarios, for which dialog lifetime is sufficient. 5. Problems with Global Reachability The original intent of a GRUU was to be globally reachable, from anywhere on the Internet. If it weren't, then one would think it would simply have the same behavior as normal non-GRUU URIs, and be no worse than using a regular Contact URI. Unfortunately, this isn't always the case. Section 4.5 of [RFC5627] has the following statement: Some UAs implement non-standard URI-handling mechanisms that compensate for the fact that heretofore many contact URIs have not been globally routable. Since any URI containing the "gr" URI parameter is known to be globally routable, a UA SHOULD NOT apply such mechanisms when a contact URI contains the "gr" URI parameter. Furthermore, [RFC5589] prescribes sending a REFER outside of the INVITE dialog if a GRUU is available, since with a GRUU the Transferor "knows the Contact URI is routable outside the dialog". Currently deployed networks that don't use or have GRUUs have implemented alternate means of making call-transfer scenarios work. If the UAs in such networks behave differently when they encounter a GRUU, and the GRUU isn't actually routable for them, the scenario will fail when it would have previously succeeded. Furthermore, if a B2BUA in the request path does not replace the Contact-URI *because* it is a GRUU, then using a GRUU that is not actually globally routable will cause failure, whereas inserting its own Contact-URI would have otherwise worked. In theory, creating a GRUU which is not globally routable is simply a user error or system defect, however in practice it's difficult if not impossible for the system or user to know a priori whether a Kaplan Expires - April 2011 [Page 7] Internet-Draft Problems with SIP GRUUs October 2010 GRUU is globally routable or not. The reasons for this are described in the following sections. 5.1. Access-Restricted Domains In practice, even if they use SIP on the public Internet, most SIP domains are access-restricted, meaning only authorized subscriber UAs and known peers are allowed to send requests into the domain. Any SIP request from unauthorized agents are rejected or discarded. This is typically done with either layer-3/4 access control lists (ACLs), SIP layer access controls, or digest authentication. Section 4.3 of [RFC5627] describes the conditions required to use a self-made GRUU, including that Firewall policies must allow requests that reference a GRUU to pass into the network. However, it is not as clear that this condition even holds for Registrar-provided GRUUs; the Registrar must not provide GRUUs if the GRUU cannot be de-referenced and used by anyone, anywhere on the Internet, to reach the Registrar. But how would a Registrar know such a thing? It can't, because the access policies aren't all implemented in the Registrar typically. Only the domain administrator humans would know this, and even then it may not be clear to them all the conditions under which their domain must be available. For example, one of the initial deployments of GRUUs involved an Enterprise SIP-based domain, where the vendor of the Enterprise SIP Registrar/Proxy and UAs used GRUUs by default. As often occurs in Enterprise deployments, a Firewall-type device was deployed between the Registrar/Proxy and the public Internet, with rules to only allow SIP in from known corporate branches, home office users, partner sites, and their SIP Trunk providers. By definition, the Firewall's policies make GRUUs no longer globally routable to the Enterprise, and thus it should not be using GRUUs. But the Enterprise IT personnel were not SIP protocol experts and had no idea they needed to change their system configurations. It is not even clear the vendor of the Registrar/Proxy systems understands those implications, because one would think they shouldn't make GRUUs a default behavior given typical Enterprise deployments. 5.2. Routing-Restricted Domains A property of many deployed SIP domains is that they cannot simply send SIP requests to anywhere on the public Internet. For example an Enterprise SIP domain with policies to only use their service providers' SIP Trunks or known partners or users, or a SIP Service Provider (SSP) with policies to only send requests to subscribers, peers, and their Enterprise customer SIP Trunks. They may even use [RFC3263] procedures with DNS to route SIP requests externally, but Kaplan Expires - April 2011 [Page 8] Internet-Draft Problems with SIP GRUUs October 2010 only to known domains with which they have a pre-existing relationship. From a high-level, such SIP domains are "routing-restricted", meaning they can only route SIP requests based on specific local policies. Routing-restricted domains are ubiquitous in SSPs, and in certain Enterprise vertical markets such as financial, medical and government sectors. The problem with using GRUUs is not that routing-restricted domains can't provide GRUUs to its UAs for use as Contact-URIs in outbound requests - technically they could if they were not also access- restricted, although most if not all routing-restricted domains are also access-restricted. The real problem is that SIP requests *sent to* the routing-restricted domain can't use GRUUs for Contact-URIs, because the routing-restricted domain itself cannot de-reference a GRUU unless the GRUU's domain happens to be one it can route to based on its local policies. Since there is virtually no way for the originating or receiving domain to know where a GRUU used in a Contact-URI may end up going to, or what the local policies of a domain that attempts to de-reference the GRUU are, they can't be used anytime safely. 5.3. IPv6 Reachability The stipulation for GRUUs in [RFC5627] is that they be globally reachable on the "public Internet". Unfortunately, there are *two* public Internets: one using IPv4 and one using IPv6. One of the non-obvious implications of "global reachability" is that the domain of the GRUU must be reachable on both, because the GRUU may be passed on to IPv6-only UAs or domains, or vice-versa. In theory, the transition to IPv6 implies that at some point there will be IPv6-only domains or UAs. If they receive a GRUU which is actually only available through IPv4, it cannot be de-referenced, unless they employ an IPv4-IPv6 interworking function for both signaling and media. A GRUU-providing domain, however, has no idea if an IPv6-only domain has such a function available. 6. Alternatives to GRUU The original motivation for defining GRUUs was to handle call- transfer scenarios, where a normal Contact URI of the established dialog might not be usable by the transferor or transferee for targeting out-of-dialog requests such as REFER or INVITE with Replaces header. For example, Alice calls Bob, who transfers her to Charlie by calling Charlie and then sending Charlie a REFER to INVITE Alice. Kaplan Expires - April 2011 [Page 9] Internet-Draft Problems with SIP GRUUs October 2010 Alternatively Alice could be the one issuing the REFER to Charlie to INVITE Bob, but the issues are the same. Either way, the REFER may be out-of-dialog but needs to reach Charlie, and Charlie's out-of- dialog INVITE needs to reach Alice (or Bob). In practice, this problem has been solved other ways than with GRUUs. The primary "solution" employed today, as far as this author can tell, is to process the REFER in a B2BUA which has the dialog information of the other dialog(s). For example, an Enterprise IP- PBX which is in the SIP signaling path for all calls to/from Bob would receive Bob's attended-transfer REFER to Charlie, accept it and generate re-INVITEs to Alice and Charlie bridging the media for the calls but without Alice or Charlie handling REFER or INVITE with Replaces. Because the IP-PBX processes the REFER itself, it need never send an out-of-dialog request to a specific UA instance to begin with. The "solution", then, is to avoid the problem altogether. Since this type of solution also removes the need for the transferee to support REFER and the transfer-target to support the Replaces header, and hides the transferee's identity, it is very popular. Furthermore, due to the proliferation of B2BUAs in the signaling path, it's not very common that a Contact URI is not routable-to by a UA. The odds are good that the Contact URI that Bob receives in a request belongs to a B2BUA that is reachable by Bob and Charlie; and thus when Bob or Charlie sends an out-of-dialog request to that Contact URI, it can be reached. If not, then it's because Charlie is outside of Bob's domain and thus Bob's REFER to Charlie goes back through the B2BUA, or through another B2BUA which can also reach the first B2BUA. It's rarely the case that there would be a Bob who could refer a Charlie that cannot reach the same B2BUA. It's possible, of course, but highly unlikely in practice. Therefore, there has rarely been a problem for GRUU to solve. Alternatively, some B2BUAs can generate "Global Contacts", as described previously in Section 4. 7. Conclusion In summary, the following points have been made: - Generating GRUUs which are not actually globally routable may cause more harm than not using GRUUs - A GRUU generator has no practical means of determining if the GRUU is globally routable, by every device which can receive it - B2BUAs should continue to replace Contact URIs, regardless of them being a GRUU or not - Access Proxies/SBCs need to take special care when handling GRUU- based Contact requests Kaplan Expires - April 2011 [Page 10] Internet-Draft Problems with SIP GRUUs October 2010 8. Security Considerations There are no specific security issues for this document, since it does not propose any new mechanism. 9. IANA Considerations There are no requirements for IANA in this document. 10. References 10.1. Informative 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. [RFC3891] Mahy, R., Biggs, B., Dean, R., "The Session Initiation Protocol (SIP) 'Replaces' Header", RFC 3891, September 2004. [RFC5589] Sparks, R., Johnston, A., Petrie, D., "Session Initiation Protocol (SIP) Call Control - Transfer", RFC 5589, June 2009. [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. Author's Address Hadriel Kaplan Acme Packet 100 Crosby Drive Bedford, MA 01703 Email: hkaplan@acmepacket.com Kaplan Expires - April 2011 [Page 11]