Network Working Group J. van Bemmel Internet-Draft Lucent Technologies Expires: March 23, 2006 September 19, 2005 Obtaining and Using Temporarily Routable User Agent (UA) URIs (TRUU) in the Session Initiation Protocol (SIP) draft-jbemmel-sip-truu-01.txt 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 March 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct a URI which can only be used to route messages to that specific UA instance for the duration of a particular call. A URI whose lifetime is controlled by the UA instance to which it indirectly routes is called a Temporarily Routable UA URI (TRUU). This document describes an extension to SIP for obtaining a TRUU from a proxy, and for using this TRUU when communicating with a peer in the context of a dialog. van Bemmel Expires March 23, 2006 [Page 1] Internet-Draft TRUU Mechanism September 2005 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Defining a TRUU . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Differences between GRUUs and TRUUs . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 8 4.2. Avoiding Direct Contact . . . . . . . . . . . . . . . . . 8 4.3. Co-Existence With End-2-End Mechanisms . . . . . . . . . . 8 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 5.1. Alternatives considered . . . . . . . . . . . . . . . . . 10 6. Creation of a TRUU . . . . . . . . . . . . . . . . . . . . . . 11 7. Obtaining a TRUU . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. User Agent Behavior . . . . . . . . . . . . . . . . . . . 13 7.1.1. Generating a REGISTER Request to obtain TRUUs . . . . 13 7.1.2. Processing the REGISTER Response . . . . . . . . . . . 14 7.2. Outbound Proxy REGISTER Behavior . . . . . . . . . . . . . 14 7.2.1. Processing the REGISTER Request . . . . . . . . . . . 14 8. Using the TRUU . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Sending a Message Containing a TRUU . . . . . . . . . . . 16 8.2. Sending a Message to a TRUU . . . . . . . . . . . . . . . 16 8.3. Receiving a Request Sent to a TRUU . . . . . . . . . . . . 16 8.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 17 8.4.1. Request Processing . . . . . . . . . . . . . . . . . . 17 8.4.2. Request Targeting . . . . . . . . . . . . . . . . . . 17 8.4.3. Record Routing . . . . . . . . . . . . . . . . . . . . 17 8.4.4. Response Forwarding . . . . . . . . . . . . . . . . . 18 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 21 12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . . 28 16.2. Informative References . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 van Bemmel Expires March 23, 2006 [Page 2] Internet-Draft TRUU Mechanism September 2005 1. Conventions used in this document 1.1. Requirements notation 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 [1]. 1.2. Terminology o ttt van Bemmel Expires March 23, 2006 [Page 3] Internet-Draft TRUU Mechanism September 2005 2. Introduction The following text is taken from [6] and equally applicable to this document: The Session Initiation Protocol (SIP), RFC 3261 [2] is used to establish and maintain a dialog between a pair of user agents in order to manage a communications session. Messages within the dialog are sent from one user agent to another using a series of proxy hops called the route set, eventually being delivered to the remote target - the user agent on the other side of the dialog. This remote target is a SIP URI obtained from the value of the Contact header field in INVITE requests and responses. RFC 3261 mandates that a user agent populate the Contact header field in INVITE requests and responses with a URI that is global (meaning that it can be used from any element connected to the Internet), and that routes to the user agent which inserted it. RFC 3261 also mandates that this URI be valid for requests sent outside of the dialog in which the Contact URI was inserted. In some situations, the 'direct contact outside of the dialog' aspect of a URI provided in the Contact header is undesirable. For example, a caller who wishes to remain anonymous, or a callee who does not wish his extension number to be exposed to the calling party, both have reasons for using a URI that is only valid for the duraction of the dialog. Such situations require the endpoint to be able to construct a URI that routes to it, but may be invalidated after the call. In addition, the endpoint must ensure that no other information in any messages it sends can be used to construct a URI for direct contact. It is now widely recognised that URIs provided as a remote target generally have a limited scope and validity which is restricted to the dialog, in contrast with the current text in RFC3261. However, there is a difference between how endpoints SHOULD treat such URIs and explicit enforcement of that. An unknowing or malicious user could still attempt to reuse a remote target URI outside of the context of the original dialog, and such an attempt might succeed. This specification formally defines a type of URI called a Temporarily Routable User Agent URI (TRUU) which has the properties of routing to the UA and being valid for a limited period of time, controlled by the UA. A TRUU can be considered a particular kind of GRUU [6] and this document borrows many of the ideas and mechanisms from that work, as well as its document structure. van Bemmel Expires March 23, 2006 [Page 4] Internet-Draft TRUU Mechanism September 2005 3. Defining a TRUU This specification focuses on a property, called the Temporarily Routable User Agent URI (TRUU) property. A URI possesses this property when the following is true: o Requested by the UA: A URI with the TRUU property is explicitly requested by a UA, and issued by the first hop proxy as a temporary URI which the proxy associates with the contact address of the UA. o Expires under control of the UA: A URI with the TRUU property persists only as long as the UA to which it resolves desires it. After the URI has expired it can no longer be used to contact the UA. The UA may explicitly expire the URI. o Routes to a Single Instance: A request sent to that URI will be routed to a specific UA instance. In that regard, it is unlike the address-of-record property. When a request is sent to a URI with the AOR property, routing logic is applied in proxies to deliver the request to one or more UAs. That logic can result in a different routing decision based on the time-of-day, or the identity of the caller. However, when a request is made to a URI with the TRUU property, the routing logic is dictated by the TRUU property. The request has to be delivered to a very specific UA instance. That UA instance has to be the same UA instance for all requests sent to that URI. o Routes only via a particular proxy: A URI with the TRUU property is routed indirectly, always and only via a particular proxy that knows how to translate it. To use it, an entity must therefore also know which proxy can resolve it. This indirect routing is essential for the type of protection it provides. o Anonymous: A URI with the TRUU property is anonymous in the sense that it cannot be used to discover the identity of the user, an associated AoR or any currently registered network contact address. o Not Correlated: A URI with the TRUU property is not syntactically correlated with other URIs with the TRUU property used by the same UA instance. Routeability for URIs with the TRUU property comes in two flavors: global routeability and restricted routeability. The former allows any UA in the Internet to use the URI (as long as it has not expired), the latter allows only UAs that in addition know the address of the proxy that issued the URI. For restricted TRUUs a van Bemmel Expires March 23, 2006 [Page 5] Internet-Draft TRUU Mechanism September 2005 proxy would use a non-existing hostname as the host part. For convenience, a URI that possesses the TRUU property is also referred to as a TRUU. A globally routeable TRUU is referred to as a global TRUU, the other form is known as a restricted TRUU. In terms of URI properties as listed in [6], TRUUs may have the following properties: o The service treatment property o The anonymous property o The alias property (when a UA is using multiple TRUUs in parallel) TRUUs can generally be used when any of the following is desired: o Anonymity in terms of identity, AoR and network contact address. o Avoiding that communication parties are able to determine that different dialogs originate or terminate at the same UA instance. o Avoiding that AoR based forwarding logic or other services are bypassed. o Avoiding DoS attacks based on flooding the UA with messages. A TRUU could be minted with the 'identity' property, by using some convention to derive the user's AoR from the TRUU. Such usage is out of scope of this document. This also applies to mechanisms based on the identity property (such as e.g. billing). 3.1. Differences between GRUUs and TRUUs Since TRUUs are similar to GRUUs in many aspects, it is worthwhile to make some of the differences explicit: o GRUUs are globally routeable, TRUUs can be too but only via a particular proxy. o GRUUs have a long lifetime (ideally as long as the AoR they belong to), TRUUs are usually short lived (typically no longer than the dialog they were used in). o Both may receive service treatment, but since TRUUs typically appear as the request URI in mid-dialog requests TRUUs usually do not receive pre-dialog service treatment. van Bemmel Expires March 23, 2006 [Page 6] Internet-Draft TRUU Mechanism September 2005 o Both may be anonymous, but when UAs adhere to the one-time usage policy of TRUUs correlation of calls is not possible. GRUUs, on the other hand, are susceptible to this. In this sense TRUUs provide more privacy. o When a GRUU is used, its usage is announced through a 'Supported: gruu' header. Usage of a TRUU should normally not be distinguishable from any other URI. van Bemmel Expires March 23, 2006 [Page 7] Internet-Draft TRUU Mechanism September 2005 4. Use Cases There are several use cases where the TRUU properties are desired by one or more parties participating in a dialog. Some coincide with use cases for privacy in general, in fact TRUUs provide an alternative for some of the mechanisms descibed in [4]. 4.1. Anonymous Calls Privacy considerations may lead a caller to desire anonymity, for example if the topic of the call is sensitive (e.g. related to private issues such as medical status) or could have legal consequences. In addition to not exposing any information that might reveal his identity, the caller could also desire to avoid callbacks and traceability of the call to a particular UA instance. 4.2. Avoiding Direct Contact Most SIP dialogs are established by sending a request to a target user's AoR, which a proxy then translates to a registered Contact address. Mechanisms specified in the consent framework [7] depend on the fact that a proxy performs such a translation, to enforce that communication is only possible after explicit consent from the target user. However, a malicious user could bypass such restrictions once a Contact address for the target user is obtained, to perform SPAM and Denial-Of-Service attacks which the consent framework is meant to prevent. This use case is a little different from privacy related issues, the user might not mind (or even wish) to give out his identity but prefers to avoid direct contact. A similar case occurs when a called user enables the SIP equivalent of a 'Calling Line Identity Restriction' (CLIR) service, to avoid exposing information about the specific terminal used to answer the call. 4.3. Co-Existence With End-2-End Mechanisms A Privacy service as specified in RFC3323 [4] may break end-to-end integrity mechanisms. For example, a UA that uses request identity [8] calculates a digest over several headers including the Contact header. A privacy service on a proxy would replace this Contact header with an anonymous one, thus acting as a B2BUA and breaking the digest verification. In other words, when a privacy service is used, the role of the authentication service cannot be assumed by the UA. When a TRUU is used, a UA may assume the role of privacy service itself. It can then also assume the role of authentication service. In other words, in some cases a TRUU may be used instead of a B2BUA to avoid breaking end-to-end mechanisms. van Bemmel Expires March 23, 2006 [Page 8] Internet-Draft TRUU Mechanism September 2005 5. Overview of Operation This section is tutorial in nature, and does not specify any normative behavior. In general, obtaining and using a TRUU is very similar to obtaining and using a GRUU. The text for this section was adopted from [6]. A UA can obtain a TRUU by generating a normal REGISTER request, as specified in RFC 3261 [2]. This request contains a Require header field with the value "truu", indicating to an outbound proxy that the UA requires this extension. The presence of this feature requests the outbound proxy to assign a TRUU to each Contact header in the REGISTER request. If the outbound proxy that the user is using also supports TRUU, the REGISTER response will contain a Contact header containing a TRUU for each Contact for which a TRUU was requested. This TRUU is a URI which the proxy guarantees will route to that UA instance, until it expires. The TRUU is associated with the contact address and the proxy that issued it. Should the client change its contact and request a TRUU, the proxy would provide a different TRUU. If the UA re-registers the same contact at a later time while requesting a TRUU for it, the proxy would also provide a different TRUU. When a UA uses a TRUU, it places the value in Contact headers used in the context of a particular dialog. In addition, it uses the hostport in the URI for Via headers it adds to generated or forwarded requests. It then sends these requests to the proxy that issued the TRUU. The proxy Record-Routes to ensure that it stays in the path for the dialog. For incoming dialog forming requests, if this proxy is not already in the path, the UA adds a Record-Route header to a dialog creating response (1xx, 2xx) on the proxy's behalf. A UA would normally not add any information to its messages that could be used to determine that a TRUU is being used. The UA may update its TRUU using target refresh requests or responses. When engaged in a dialog, a UA using a TRUU must ensure that it does not expire. To do so, the UA periodically sends a REGISTER request with Contact headers each containing a parameter 'truu' with the TRUU it wishes to stay valid, again using a Require header with an option of 'truu'. The proxy updates the expiration interval for the TRUUs, and adds Contact headers to the response with the refreshed TRUUs (with matching 'trid') with updated 'expires' values. At any point in time a UA may choose to explicitly invalidate a TRUU. To do so, it sends a REGISTER containing a Contact header with the current TRUU in a 'truu' parameter and 'expires=0', for each TRUU it wants to invalidate. It may request new TRUUs for the corresponding contacts by adding them twice, one with the current 'truu' parameter van Bemmel Expires March 23, 2006 [Page 9] Internet-Draft TRUU Mechanism September 2005 and 'expires=0', and a second one with a different 'trid'. It also adds a Require header with a 'truu' value. The proxy invalidates the TRUU(s), and adds any newly generated TRUUs to the response. Without all this, the TRUUs would eventually expire. 5.1. Alternatives considered Instead of the outbound proxy, a UA could generate a random Contact URI itself for use as remote target. Such a URI would still have to meet the routeability criterium, and therefore would have either the IP address or a registered hostname of the UA. In case the UA uses a dynamic IP address, it could invalidate the URI by requesting a new IP address. Although this would work (for those UAs with dynamic IP), it is considered undesirable to change the IP address after each dialog. Such changes would impact other ongoing dialogs. In addition, the same IP address could be issued to another client (possibly the same UA) making the URI routeable again. When the UA uses a private IP address, the remote contact URI automatically has the properties of (more or less) anonymity and indirect routeability. Expiry would occur naturally for most NAT configurations. Correlation of calls would be less than in a GRUU case, but stronger than in case of TRUUs since the same hostname (private IP) would be used each time, as opposed to a proxy hostname (or IP) shared by multiple UAs. Multiple random URIs could be used in parallel, but their lifetimes would not be independent; all would expire simultaneously, but not under control of the UA. So this approach could work (with some limitations), but only when private IP addresses and NAT are used. UAs (in particular mobile ones) generally do not have a say in this. van Bemmel Expires March 23, 2006 [Page 10] Internet-Draft TRUU Mechanism September 2005 6. Creation of a TRUU A TRUU is a URI that is created and maintained by a proxy authoritative for the domain in which the TRUU resides. Independently of whether the TRUU is created as a result of a registration or some other means, the proxy maintains a mapping of the TRUU to the contact address with which it is associated. Note that the 'Instance ID' which plays a key role with GRUUs has no significance for TRUUs. The reason is that GRUUs must be valid longer than a particular registration (AoR/Contact association), while TRUUs must not. A TRUU is associated - in a many (TRUU) to one (contact) fashion - with a particular contact address. This contact address, in turn, is bound to a particular AoR. The TRUU uniquely determines the contact address (hostname or IP address, including port and transport) of the UA that requested the TRUU, but this translation knowledge is not shared outside the proxy that issued the TRUU. The lifetime of the TRUU is limited by an expiration interval (hinted by the UA but determined by the proxy). This specification does not mandate a particular mechanism for construction of the TRUU. However, the TRUU MUST exhibit the following properties: o The domain part MUST be a hostname for which the resolution procedures of RFC 3263 [3] either give no result or result in the IP address of the proxy that issued the TRUU (or an equivalent machine with access to the translation knowledge). o When global routeability is not desired, the domain part MUST be a non-existing hostname. o The hostname MUST be unique across all non-expired TRUUs for which the proxy maintains a mapping. o When a TRUU was received as a remote target in a dialog and a request is sent to the TRUU while it has not expired, it routes to a proxy that can make sure the request is delivered to the UA instance. This must be the first hop proxy used by that UA for dialog creating requests. For TRUUs created through registrations, this means that this first hop proxy must either be on the REGISTER route or be known by the registrar. o The identity of the user (AoR) or contact address for the UA can not be determined from the TRUU, except by the proxy that issued it. van Bemmel Expires March 23, 2006 [Page 11] Internet-Draft TRUU Mechanism September 2005 o For each TRUU, both the SIP and SIPS versions MUST exist When a domain constructs a URI with the TRUU properties, it MAY confer other properties upon this URI as a matter of domain policy. Of course, the AOR property cannot also be provided, since the TRUU and AOR properties are mututally exclusive. However, a domain can elect to confer properties like identity, anonymity, and service treatment. There is nothing in this specification that can allow the recipient of the TRUU to determine which of these properties have been conferred to the URI, not even the TRUU property itself. The service treatment property merits further discussion. Typically, the services a proxy executes upon receipt of a request sent to a TRUU will be a subset of those executed when a request is sent to the AOR. Requests that are outside of a dialog may be dropped depending on domain policy. The intent of restricted TRUUs is to target a specific UA instance within the context of a single dialog, which is incompatible with forwarding operations. When used as remote target in dialog forming requests and responses, only mid-dialog requests will be sent to TRUUs. In this case a proxy SHOULD only apply services that are meaningful for mid-dialog requests generally speaking. This excludes screening functions, as well as forwarding ones. For any particular AOR there can be a potentially infinite number of TRUUs, zero or more for each registered contact. When issued, a TRUU MUST have a limited lifetime bound by an expiration interval. Unlike GRUUs this property is easily achievable through software failures and power outages within a network; such an event will automatically expire all TRUUs at the proxy. van Bemmel Expires March 23, 2006 [Page 12] Internet-Draft TRUU Mechanism September 2005 7. Obtaining a TRUU A TRUU can be obtained in many ways. This document only defines one - through registrations. The TRUUs may subsequently be refreshed or invalidated using any request. 7.1. User Agent Behavior 7.1.1. Generating a REGISTER Request to obtain TRUUs When a UA compliant to this specification generates a REGISTER request (initial or refresh) to obtain one or more TRUUs, it MUST include the Require header field in the request. The value of that header field MUST include "truu" as one of the option tags. The UA SHOULD include the option tag "path" (see RFC3327 [5]) as a header field value in all Supported header fields, and SHOULD include a Supported header field in all REGISTER requests (both regular ones and TRUU registrations). The Path mechanism is needed to ensure that the proxy used for resolving TRUUs is in the path for both incoming and outgoing requests. The UA MUST add each Contact header for which it requires a TRUU. The URI in this Contact header MUST be equal to a registered Contact address; it MUST NOT be a TRUU itself. The UA MUST add a 'trid' parameter to the URI in each Contact header. The value of this parameter is a token which MUST be unique across all Contact headers inserted. The UA MUST add an 'expires' parameter to each Contact header. The value of this parameter is the remaining lifetime time (in seconds) of that Contact, as assigned by the registrar. The UA MAY add a 'gr' flag parameter to each Contact header for which it desires a globally routeable TRUU. By default (i.e. when this flag is not present) a restricted TRUU is issued, which can only be used by parties that know which proxy issued it. This is typically learned through construction of the route set of a particular dialog. If a UA instance has registered against multiple AORs, it is RECOMMENDED that a UA instance use a different contact URI for each AOR, and request a different TRUU for each. This is needed for the UA to determine which TRUU to use as the remote target in responses to incoming dialog forming requests. Besides the procedures discussed above, the REGISTER request is constructed identically to the case where this extension was not van Bemmel Expires March 23, 2006 [Page 13] Internet-Draft TRUU Mechanism September 2005 understood. For regular REGISTER requests, a UA MAY include a TRUU as its Contact header. When it does, it MUST also include a Proxy- Require header with an option value of 'truu'. 7.1.2. Processing the REGISTER Response If the response is a 2xx, it may contain Contact headers. These headers contain a SIP or SIPS URIs that represent TRUUs corresponding to the contacts which the UA included in the REGISTER request, with a matching 'trid' parameter and an 'expires' parameter with a value indicating the TRUU's lifetime. The URI will be a SIP URI if the contact contained a SIP URI, else it will be a SIPS URI if the contact contained a SIPS URI. Any requests sent to the TRUU URI will be routed by the proxy to the corresponding contact address using the associated transport. The TRUU may change in subsequent 2xx responses to REGISTER. If the UA lets the TRUU expire, when it re- registers its contact at any later time, the proxy will provide a different TRUU for the same contact. As a result, a UA MUST expect to receive a different TRUU for the same contact in a subsequent registration response, and MUST discard any TRUUs for which an updated value is received. A UA MUST ignore any Contact headers in a non-2xx response to the REGISTER request. If the response is a '420 Bad Extension', the UA MUST NOT retry the request. If the response is a '305 Use Proxy', the UA SHOULD retry the request once using the indicated Contact address. 7.2. Outbound Proxy REGISTER Behavior The outbound proxy referred to in this section is the first proxy that receives the REGISTER request. This role MAY be assumed by the same element that takes the role of registrar. If the outbound proxy for REGISTER requests is different from the one(s) the client uses for other requests, the proxy that receives the REGISTER for TRUUs is responsible for making sure that those other proxies can properly translate TRUUs; the way in which this is achieved is implementation specific and out of scope of this document. 7.2.1. Processing the REGISTER Request When a proxy compliant with this specification receives a REGISTER request, it MUST check if the request contains a Require header with a value of 'truu'. If so, it MUST continue processing as described below. If not, it MUST continue processing as it would have done without this specification. Next, it MUST check that the request contains exactly 1 Via header. van Bemmel Expires March 23, 2006 [Page 14] Internet-Draft TRUU Mechanism September 2005 If it contains no such headers, the proxy MUST respond with a '400 No Via Headers'. If there is more than one Via header, the proxy MUST respond with a '305 Use Proxy' with a Contact header providing an address which is directly reachable by the UA. A proxy MAY create a TRUU for a particular contact at any time. Of course, if a UA requests a TRUU in a registration, and the proxy has not yet created one, it will need to do so in order to add it to the registration response. However, the proxy can create the TRUU in advance of any request from a UA, as long as it maps to the correct Contact address. A proxy MUST create both the SIP and SIPS versions of the TRUU, such that if the TRUU exists, both URIs exist. A TRUU issued by a proxy MAY contain a port component, which MAY not match the port of the Contact address. The transport of an issued TRUU MUST match that of the corresponding Contact; if the proxy does not support that transport it MUST NOT issue the TRUU. The request MAY have an Expires header with a value indicating the registration lifetime of contacts. Each Contact header MAY have an 'expires' parameter overriding this value. The proxy MUST append a Contact header to a 2xx response for each Contact for which a TRUU was generated, refreshed or invalidated. Each such header MUST include an 'expires' parameter, with a value equal to 0 for expired TRUUs and a value equal to the expiration time (in seconds) for valid TRUUs. Each such header MUST also include a 'trid' parameter, with a token value matching the value provided by the UA in the corresponding Contact header in the request. The proxy MUST add a Supported header with an option value of 'truu'. van Bemmel Expires March 23, 2006 [Page 15] Internet-Draft TRUU Mechanism September 2005 8. Using the TRUU 8.1. Sending a Message Containing a TRUU A UA first obtains a TRUU using the procedures of Section 7, or by other means outside the scope of this specification. A UA can use the TRUU when populating the Contact header field of requests and responses. In other words, a UA compliant to this specification MAY use a TRUU as its remote target. If the UA instance has obtained multiple TRUUs (each for a different Contact) through a registration, it MUST use the one corresponding to the network interface used to send or receive the request or response. In those requests where the TRUU is used as the remote target, the UA MUST use the hostport part of that TRUU when populating the sent-by value of the Via header it adds. It is not necessary for a UA to know whether or not its peer in the dialog supports this specification before using one as a remote target. A message for which a TRUU is used MUST be sent via the proxy that issued that TRUU; that proxy MUST be the next hop. The UA MUST add a Proxy-Require header with an option value of 'truu'. 8.2. Sending a Message to a TRUU There is no new behavior associated with sending a request to a TRUU. A TRUU is a URI like any other. In fact, a UA should not be able to distinguish a TRUU from any other URI. 8.3. Receiving a Request Sent to a TRUU When a UAS receives a request sent to a TRUU, the incoming request URI will be equal to the contact that is associated with that TRUU (through REGISTER or some other way) by that UA instance, including a 'trid' parameter with a token value that the UA can use to distinguish amongst various Contacts it used. A request sent to a TRUU will usually be a mid-dialog request, with a dialog identifier that should match an ongoing dialog at the UAS. There are some cases in which a TRUU can occur in a dialog initiating request. For example (non-exhaustive): o When the other party used REFER and put the TRUU in a Refer-To header. van Bemmel Expires March 23, 2006 [Page 16] Internet-Draft TRUU Mechanism September 2005 o When the TRUU appeared in a Presence document, and some entity picked it up from there. o In case of ad-hoc conferencing. It is up to local policy whether the UAS accepts such requests. If it does, it SHOULD use a different TRUU as a remote target in any Contact headers used in the context of the new dialog. 8.4. Proxy Behavior Proxy behavior is fully defined in Section 16 of RFC 3261, extended with Path processing defined in RFC3327 [5]. TRUU processing impacts that processing in several places - Request processing and targeting, record-routing and response forwarding. 8.4.1. Request Processing When a proxy receives a request from a UA containing a Proxy-Require header with an option value of 'truu' and a Via header with a hostport it recognises as a part of a TRUU it issued, it MUST NOT add a 'received' parameter reflecting the IP address of the UA. Instead, it MUST insert one of its own IP addresses. The proxy MUST remove any Proxy-Require headers with a value of 'truu'. 8.4.2. Request Targeting When a proxy server receives a request, and the request URI is within the domain of the proxy, and the URI has been constructed by the domain such that the proxy is able to determine that it has the form of a TRUU it issued that is now unknown or expired, the proxy rejects the request with a 404. If the TRUU does exist and is not expired, the request target MUST be obtained by taking the corresponding contact, including the 'trid' parameter. The result MUST be used as Request URI. A proxy MAY apply other processing to the request, such as execution of called party features. A request sent to a TRUU SHOULD NOT be redirected. 8.4.3. Record Routing A proxy compliant with this specification MUST insert a Record-Route header in every dialog creating request that contains a Contact van Bemmel Expires March 23, 2006 [Page 17] Internet-Draft TRUU Mechanism September 2005 header with a TRUU issued by the proxy and a Proxy-Require header with a value of 'truu'. TBD: Is it OK if the UA adds a Record-Route on the proxy's behalf to an incoming dialog creating request, if the proxy did not do so? 8.4.4. Response Forwarding When the proxy removes the topmost Via header from a response to be forwarded, it MUST inspect the sent-by value. If this value matches a hostport portion of a TRUU issued by this proxy, it MUST perform a mapping from this hostport to the contact address of the UA, and forward the response there. In this case it MUST NOT perform a DNS lookup. The way in which the Via's hostport part is matched against a TRUU format is implementation specific. van Bemmel Expires March 23, 2006 [Page 18] Internet-Draft TRUU Mechanism September 2005 9. Grammar TBD van Bemmel Expires March 23, 2006 [Page 19] Internet-Draft TRUU Mechanism September 2005 10. Requirements This specification was created in order to meet the following requirements: REQ 1: When a UA invokes a TRUU which has not expired in the context of a dialog in which that TRUU was received as remote target, it MUST cause the request to be routed to the specific UA instance to which the TRUU refers. REQ 2: A TRUU SHOULD be restricted as much as possible for use only in the context of a specific dialog. It SHOULD be restricted to use within a specific addressing realm. REQ 3: The network MUST store additional state regarding the mapping of the TRUU to the associated contact address. It MUST be possible to remove this state, in particular upon request by the UA to which it refers. REQ 4: It MUST be possible for a UA to obtain a multiplicity of TRUUs, each one of which routes to that UA instance. This is needed to support ad-hoc conferencing, for example, where a UA instance needs a different URI for each conference it is hosting. REQ 5: When a UA receives a request sent to a TRUU, it MUST be possible for the UA to know the TRUU which was used to invoke the request. This is necessary as a consequence of requirement 4. REQ 6: It MUST be possible to restrict usage of a TRUU to a particular dialog. When a TRUU has expired, requests targeted at that TRUU MUST result in an error response from a proxy; the UA MUST NOT receive them. REQ 7: It MUST be possible for a UA in a dialog to inform its peer of its TRUU, but it SHOULD NOT be possible for the peer to know that the URI represents a TRUU. van Bemmel Expires March 23, 2006 [Page 20] Internet-Draft TRUU Mechanism September 2005 11. Example Call Flow The following call flow shows a basic TRUU registration and call setup, with a callee using a TRUU and a proxy also acting as registrar. Caller(192.0.2.1) Proxy(192.0.2.2) Callee(192.0.2.3) | |(1) REGISTER | | |<--------------------| | |(2) 200 OK | | |-------------------->| |(3) INVITE | | |-------------------->| | | |(4) INVITE | | |-------------------->| | |(5) 200 OK | | |<--------------------| |(6) 200 OK | | |<--------------------| | |(7) ACK | | |-------------------->| | | |(8) ACK | | |-------------------->| | | | ~ ~ (9) BYE ~ | (10) BYE |<--------------------| |<--------------------| | | (11) 200 OK | | |-------------------->| | | | (12) 200 OK | | |-------------------->| | | | | | | | |(13) REGISTER | | |<--------------------| | |(14) 200 OK | | |-------------------->| The Callee supports the TRUU extension. As such, its REGISTER (1) to obtain a TRUU looks like: van Bemmel Expires March 23, 2006 [Page 21] Internet-Draft TRUU Mechanism September 2005 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.3;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Callee ;tag=a73kszlfl Supported: path Require: truu To: Callee Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3 CSeq: 1 REGISTER Contact: ;expires=3600 Content-Length: 0 The REGISTER response would look like: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.3;branch=z9hG4bKnashds7 From: Callee ;tag=a73kszlfl To: Callee ;tag=b88sn Supported: path, truu Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3 CSeq: 1 REGISTER Contact: ;expires=3600 Note how the Indirect-Contact header field in the REGISTER response contains the TRUU (sip:x@h1.example.com) and a 'trid' parameter matching the one in the Contact supplied by the UAC. This TRUU translates to the contact address of 192.0.2.3 (using some internal mapping table, outside the scope of this specification). The proxy selected an expiration interval equal to that of the registered contact. There is no 'Supported: truu' header in the response, although in this scenario the proxy (acting as a registrar) could have inserted it. The presence of Indirect-Contact headers is sufficient for the UA to determine support. The INVITE from the caller is a normal SIP INVITE sent to sip:callee@example.com. The 200 OK generated by the callee (message 6), however, now contains a TRUU as the remote target (in the Contact header). van Bemmel Expires March 23, 2006 [Page 22] Internet-Draft TRUU Mechanism September 2005 SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a From: Caller ;tag=n88ah To: Callee ;tag=a0z8 Call-ID: 1j9FpLxk3uxtma7@192.0.2.1 CSeq: 1 INVITE Allow: INVITE, OPTIONS, CANCEL, BYE, ACK Contact: Content-Length: --- Content-Type: application/sdp [SDP Not shown] The following message shows what the BYE request sent by the callee looks like, at the point after it passed through the proxy. BYE sip:caller@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKe98a Via: SIP/2.0/UDP h1.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.2 Max-Forwards: 69 From: Callee ;tag=a0z8 To: Caller ;tag=n88ah Call-ID: 1j9FpLxk3uxtma7@192.0.2.1 CSeq: 1 BYE Content-Length: 0 Notice how the callee UAC takes care not to reveal any information that would expose its Contact address. The Via sentby value is set to the hostport part of the TRUU, and the proxy appends its own IP address in the 'received' parameter. The UAC included a Proxy- Require: truu in its BYE request (9), but this is not visible to the receiver (caller). van Bemmel Expires March 23, 2006 [Page 23] Internet-Draft TRUU Mechanism September 2005 12. Open issues o A UAC could indicate it's using a TRUU (Supported: truu), a receiving UA should then not use the contact outside of the current dialog (not store it, etc). van Bemmel Expires March 23, 2006 [Page 24] Internet-Draft TRUU Mechanism September 2005 13. Security Considerations It is recommended that the UA use an integrity protected transport towards the first proxy. van Bemmel Expires March 23, 2006 [Page 25] Internet-Draft TRUU Mechanism September 2005 14. IANA Considerations TBD van Bemmel Expires March 23, 2006 [Page 26] Internet-Draft TRUU Mechanism September 2005 15. Acknowledgements Large portions of this work are based on GRUU [6] and Privacy related issues [8]. The author acknowledges the authors and contributors of those documents. This work is part of the Freeband AWARENESS project (http://awareness.freeband.nl). Freeband is sponsored by the Dutch government under contract BSIK 03025. van Bemmel Expires March 23, 2006 [Page 27] Internet-Draft TRUU Mechanism September 2005 16. References 16.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [5] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [6] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-04 (work in progress), July 2005. 16.2. Informative References [7] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", draft-ietf-sipping-consent-framework-02 (work in progress), July 2005. [8] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in progress), May 2005. van Bemmel Expires March 23, 2006 [Page 28] Internet-Draft TRUU Mechanism September 2005 Author's Address Jeroen van Bemmel Lucent Technologies Larenseweg 50 Hilversum The Netherlands Email: jbemmel@lucent.com URI: http://www.lucent.com van Bemmel Expires March 23, 2006 [Page 29] Internet-Draft TRUU Mechanism September 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. van Bemmel Expires March 23, 2006 [Page 30]