Network Working Group J. van Bemmel Internet-Draft Lucent Technologies Expires: November 13, 2006 May 12, 2006 Obtaining and Using Temporarily Routable User Agent (UA) URIs (TRUU) in the Session Initiation Protocol (SIP) draft-jbemmel-sip-truu-02.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 November 13, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 a time limited period, for example only 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 registrar, and for using this TRUU as a Contact. van Bemmel Expires November 13, 2006 [Page 1] Internet-Draft TRUU Mechanism May 2006 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Defining a TRUU . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Comparison between GRUUs and TRUUs . . . . . . . . . . . . 7 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Privacy Preserving Call Transfer . . . . . . . . . . . . . 9 4.2. Calls With Anonymity of Location / Without Callback Option . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Privacy Enhanced Presence . . . . . . . . . . . . . . . . 10 4.4. Avoiding Direct Contact . . . . . . . . . . . . . . . . . 10 4.5. Co-Existence With End-2-End Mechanisms . . . . . . . . . . 11 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 12 5.1. Alternatives considered . . . . . . . . . . . . . . . . . 13 6. Creation of a TRUU . . . . . . . . . . . . . . . . . . . . . . 14 7. Obtaining a TRUU . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. User Agent Behavior . . . . . . . . . . . . . . . . . . . 16 7.1.1. Generating a REGISTER Request to obtain TRUUs . . . . 16 7.1.2. Processing the REGISTER Response . . . . . . . . . . . 16 7.1.3. Invalidating a TRUU . . . . . . . . . . . . . . . . . 17 8. Registrar REGISTER Behavior . . . . . . . . . . . . . . . . . 18 8.1. Processing the REGISTER Request . . . . . . . . . . . . . 18 8.2. Constructing the REGISTER 2xx response . . . . . . . . . . 18 9. Using the TRUU . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Sending a Message Containing a TRUU . . . . . . . . . . . 20 9.2. Sending a Message to a TRUU . . . . . . . . . . . . . . . 21 9.3. Receiving a Request Sent to a TRUU . . . . . . . . . . . . 21 9.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 22 9.4.1. Request Processing . . . . . . . . . . . . . . . . . . 22 9.4.2. Request Targeting . . . . . . . . . . . . . . . . . . 23 9.4.3. Record Routing . . . . . . . . . . . . . . . . . . . . 23 9.4.4. Response Forwarding . . . . . . . . . . . . . . . . . 24 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 28 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 14. Change history . . . . . . . . . . . . . . . . . . . . . . . . 33 14.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 33 15. Security Considerations . . . . . . . . . . . . . . . . . . . 34 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 18.1. Normative References . . . . . . . . . . . . . . . . . . . 37 18.2. Informative References . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 40 van Bemmel Expires November 13, 2006 [Page 2] Internet-Draft TRUU Mechanism May 2006 1. Conventions used in this document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. This specification uses the same terminology as defined in the GRUU draft [5] regarding "contact", "remote target" and "Contact header field". In addition, it uses the following terms: Routable: A URI is "routable" when a request targeted at that URI can be delivered to the User Agent represented by that URI. Global: Used as an adjective, "globally", to indicate Internet scope. For example, "globally routable" means routable across the Internet. Temporary: Used as an adjective, "temporarily", to indicate a time-limited aspect. For example, "temporarily routable" means routable for a limited period of time. van Bemmel Expires November 13, 2006 [Page 3] Internet-Draft TRUU Mechanism May 2006 2. Introduction The following text is taken from [5] 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 'valid 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 caller who does not wish to be called back directly by the called party, both have reasons for using a URI that is only valid for a limited period of time, preferably only for the duration of the dialog. Such situations require the endpoint to be able to construct a URI that routes to it but becomes invalid after the call. It is now widely recognized 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 very well succeed. In current deployments, the URI used in the Contact header may already have the property of being valid only for a limited time. This is for example the case when dynamic IP addresses are used (e.g. obtained through DHCP) and/or when a firewall/NAT device is present. Although this is often considered undesirable (and in need of solutions such as outbound [10]), the ephemeral nature of such a contact can provide automatic and adequate protection against some forms of unwanted future calls, and (to a limited extend) protection against correlation over time. van Bemmel Expires November 13, 2006 [Page 4] Internet-Draft TRUU Mechanism May 2006 This specification formally defines a type of URI called a Temporarily Routable User Agent URI (TRUU) which has the properties of routing to a specific UA and being valid for a limited period of time, controlled by the UA. A TRUU can be considered a particular kind of GRUU [5] and this document borrows many of the ideas and mechanisms from that work, as well as its document structure. van Bemmel Expires November 13, 2006 [Page 5] Internet-Draft TRUU Mechanism May 2006 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 registrar as a temporary URI which it associates with a current 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 Global: It can be used by any User Agent Client (UAC) connected to the Internet, just like a GRUU. In that regard, it is like the address-of-record (AOR) property. A URI with the AOR property (for example, sip:joe@example.com), is meant to be used by anyone to reach that user. The same is true for a URI with the TRUU property, albeit for a limited period of time. o Routes to a Single Contact: A request sent to that URI will be routed to a specific UA Contact address. 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 local policy (which may depend on time-of-day, the identity of the caller, etc ). 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 contact address. While the TRUU has not expired, that UA contact is the same 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. This indirect routing is essential for the type of protection a TRUU 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. [TBD this is optional] 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. [TBD this is optional] van Bemmel Expires November 13, 2006 [Page 6] Internet-Draft TRUU Mechanism May 2006 TRUUs could also be constructed to receive special service treatment. For convenience, a URI that possesses the TRUU property is also referred to as a TRUU. 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 by callers. o Avoiding SPAM or DoS attacks based on flooding the UA with messages sent directly to its contact address. o Targeting a specific UA (avoiding certain routing / forking logic) 3.1. Comparison between GRUUs and TRUUs Since TRUUs are similar to GRUUs in many aspects, it is worthwhile to make some of the commonalities and differences explicit: o Both GRUUs and TRUUs are globally routable. 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 are used in). o Both may receive service treatment. o Both may be distributed using the same mechanisms. 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 anonymity. o Once a GRUU is shared with a peer it cannot be revoked. From that moment on (until the GRUU becomes invalid, i.e. typically until the AoR is removed) the GRUU can be used to "bother" the UA to which it routes. o A GRUU is bound to an instance id, a TRUU is bound to a particular contact address (only known by the proxy who issued it). van Bemmel Expires November 13, 2006 [Page 7] Internet-Draft TRUU Mechanism May 2006 o A request containing a TRUU as Contact may fail because the TRUU has expired. A request using a GRUU is less likely to fail in this way. The TRUU mechanism can be viewed as an extension to GRUU. All TRUUs are also GRUUs, but not all GRUUs are TRUUs. In other words, TRUUs are a special type of GRUUs. van Bemmel Expires November 13, 2006 [Page 8] Internet-Draft TRUU Mechanism May 2006 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 described in [4]. 4.1. Privacy Preserving Call Transfer Consider a call transfer scenario in which the transferor wishes to protect the transferee (e.g., a secretary protecting her boss), such that the transfer target will not be able to contact the transferee directly outside of the current transfer. For this purpose, a slightly modified call flow from [11] section 6.2 could be used: F1 INVITE Transferee -> Transferor (using TRUU) Contact: ... F5 REFER Transferor -> Transfer Target (using TRUU) Refer-To: Instead of using a GRUU in the Contact header, the transferee uses a TRUU. This Contact is then used in the Refer-To header. The transfer target can use this URI to contact the transferee, but only as long as the TRUU remains valid. Note that nothing changes for the transferor, the choice of using a TRUU is at the discretion of transferee. (Note that "truu1" would probably not meet the requirements for a TRUU, it is only provided as a hypothetical example). In a similar fashion, other call transfer scenarios can be adapted to provide privacy protection for one or more parties involved. The way in which TRUUs for other parties are obtained is out of scope, but for example PIDF [7] could be used. 4.2. Calls With Anonymity of Location / Without Callback Option 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 the call could have legal consequences. Likewise, a caller could desire to avoid callbacks and/or traceability of the call to a particular UA instance or network address (which often implies at least a geographical region), and/or correlation with other calls (i.e. protection against profiling). van Bemmel Expires November 13, 2006 [Page 9] Internet-Draft TRUU Mechanism May 2006 Note that TRUUs only provide protection against tracing by the remote party. The proxy that issues and manages the TRUU can still perform such tracing. 4.3. Privacy Enhanced Presence From [5] : In a SIP-based presence [6] system, the Presence Agent (PA) generates notifications about the state of a user. This state is represented with the Presence Information Document Format (PIDF) [7]. In a PIDF document, a user is represented by a series of tuples, each of which describes the services that the user has. Each tuple also has a URI in the element, which is a SIP URI representing that service. A watcher can make a call to that URI, with the expectation that the call is routed to the service whose presence is represented in the tuple. Though access control mechanisms may be used to restrict the set of users to which contacts from a PIDF document are distributed, it only takes one leak to expose a contact to external parties. Worms or viruses may infect the system of a careless buddy, and can subsequently cause mayhem through the direct, globally routable contact. Ultimately, the only available option would then be to invalidate the GRUU (and to notify everyone who depends on its global, long-lived routability). When TRUUs are used to populate the element in PIDF documents, the risk of exposure to unwanted traffic is much reduced. TRUUs can provide the required 'global routability' property (like GRUUs) but without the 'long-lived' property. The separation of these URI properties provides some protection against the scenario sketched above. A consequence is that the PIDF document containing the contacts will have to be refreshed periodically (which may already occur naturally due to the soft state nature of publications). 4.4. 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 [8] 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 separate from privacy related to identity, the user might not mind (or even wish) to give out his identity but could prefer to avoid direct contact. A similar case occurs when a van Bemmel Expires November 13, 2006 [Page 10] Internet-Draft TRUU Mechanism May 2006 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.5. 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 [9] 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 (when 'header' privacy level is requested), thus acting as a B2BUA and breaking the digest verification. In other words, when a privacy service is used at the 'header' level, 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 the TRUU mechanism may be used instead of a B2BUA to avoid breaking other end-to-end mechanisms. At first glance the combination of "privacy" and "identity" might seem odd, since they appear mutually exclusive. However, TRUUs enable a fourth level of privacy (in addition to "header", "session" and "user" privacy levels defined in [4]) which one might describe as "contact" privacy. This loosely corresponds to the freedom to decide if some other party may directly contact you in the future. The combination of contact privacy with identity is quite common in communications (i.e. you know who you are talking to, but do not have a means to contact the other party). The TRUU mechanism requires the use of intermediary elements, which stay in the signaling path for the duration of the call. However, as [4] observes: the participation of intermediaries is crucial to providing privacy in SIP. TRUUs merely form an addition to the arsenal of available countermeasures. van Bemmel Expires November 13, 2006 [Page 11] Internet-Draft TRUU Mechanism May 2006 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 [5]. 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 the registrar that the UA requires this extension. The presence of this feature requests the registrar to assign one or more TRUUs to each Contact header with a 'trid' parameter in the REGISTER request. If the registrar supports TRUU, the REGISTER response will contain Indirect-Contact headers containing a TRUU, one or more for each Contact for which a TRUU was requested. This TRUU is a URI which the registrar guarantees will route to that UA contact, until it expires. The TRUU is associated with the contact address and the registrar that issued it. Should the client change its contact and request a TRUU, the registrar would provide a different TRUU. If the UA re-registers the same contact at a later time while requesting a TRUU for it, the registrar would also provide a different TRUU. Note that all TRUUs have independent lifetimes, each may be expired explicitly. When a UA uses a TRUU, it places the value in Contact headers used in the context of a particular dialog. In addition, it may use the host part of the TRUU as the sent-by host in Via headers it adds to generated or forwarded requests. It adds a 'Require: truu' header and a 'Proxy-Require: hide-ip' and then sends the request to the outbound proxy. The proxy does not set the 'received' parameter to the IP address of the UAC, but instead remembers sufficient state to be able to forward any responses. The registrar checks that the TRUU Contact is valid for a sufficient time period and removes the 'Require: truu' header. The request is then forwarded to its destination as usual. For incoming dialog forming requests, the registrar adds a Record- Route to stay in the route set. For incoming mid-dialog requests, the registrar in addition rewrites the request URI (i.e. a TRUU) to the corresponding Contact address. A UA would normally not add any information to its messages that could be used to determine that a TRUU is being used. When engaged in a dialog, a UA using a TRUU must ensure that it does not expire. To do so, it periodically requests a fresh TRUU, and updates its peer using target refresh requests or responses. At any point in time a UA may choose to explicitly invalidate a TRUU. van Bemmel Expires November 13, 2006 [Page 12] Internet-Draft TRUU Mechanism May 2006 To do so, it sends a special REGISTER request to the registrar, containing Indirect-Contact headers with the TRUU(s) to be invalidated. 5.1. Alternatives considered Instead of the registrar, a UA could generate a random Contact URI itself for use as remote target. Such a URI would still have to meet the routability criterion, and therefore would have either the IP address or a registered hostname of the UA. An approach where the UA would obtain the hostname of a TRUU-forwarding proxy is FFS. 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 routable again. When the UA uses a private IP address, the remote contact URI automatically has the properties of (more or less) anonymity and indirect routability. 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. [12] describes a similar approach to privacy, including a mechanism to obtain privacy-preserving values for Contact and To headers from a server, and IP addresses for media. It suggests the use of encryption to form anonymous URIs from AoRs. This draft does not mandate any particular implementation (an alternative would e.g. be translation tables). van Bemmel Expires November 13, 2006 [Page 13] Internet-Draft TRUU Mechanism May 2006 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 is responsible for associating the TRUU with the contact address to which it applies. 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, 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 RFC3263 [3] result in the IP address of the proxy that issued the TRUU (or an equivalent machine with access to the translation knowledge, e.g. in case of proxy farms). o The TRUU MUST be unique (in a case-insensitive way, as defined by URI comparison rules) across all non-expired TRUUs that the proxy issued. o The TRUU MUST NOT correlate with other TRUUs that the proxy issued, except for the scheme, host part, the 'gruu' and possibly 'transport' and 'user' parameters. o When a request is sent to a TRUU which has not yet expired, it MUST resolve to a proxy that can make sure the request is delivered to the UA contact. o The identity of the user (AoR) or contact address for the UA SHOULD NOT be derivable (in a cryptographic sense) from the TRUU, except by the proxy that issued it. van Bemmel Expires November 13, 2006 [Page 14] Internet-Draft TRUU Mechanism May 2006 o For each TRUU, both the SIP and SIPS versions MUST exist. o The 'transport' parameter in an issued TRUU MUST match that parameter in the corresponding Contact URI. If this parameter is not present in the Contact, the TRUU MUST NOT have this parameter. It MUST however work for all transports supported by the issuing proxy. o An issued TRUU MUST NOT have a 'grid' parameter. o The lifetime of an issued TRUU SHOULD NOT exceed the lifetime of the corresponding registered Contact [TBD perhaps this is too strict] o A TRUU MUST have a 'gruu' parameter to identify it as a valid GRUU (see [5]). A TRUU MAY have an 'opaque' parameter, although if the anonymity property is desired the user's AoR MUST NOT be put in here. When a domain constructs a URI with the TRUU property, 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 mutually 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, except the global routability property. 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. A request which has a TRUU as request URI MUST NOT be forwarded to more than one destination. 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. van Bemmel Expires November 13, 2006 [Page 15] Internet-Draft TRUU Mechanism May 2006 7. Obtaining a TRUU A TRUU can be obtained in many ways. This document only defines one - through registrations. 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 a Require header field in the request. The value of this header field MUST include "truu" as one of the option tags. The UA MUST add a 'trid' parameter to each Contact header for which a TRUU is desired. The value of this parameter is a token which MUST be unique across all Contact headers inserted. This parameter is used to correlate the assigned TRUUs with their associated Contacts in the REGISTER response. The UA MAY add a 'truu-count' parameter to a Contact header for which it requests a TRUU, indicating the number of TRUUs desired for that Contact. The value MUST be numeric and MUST NOT be '0'. The value SHOULD NOT exceed '10'. If not present, a default value of '1' is assumed. Note that the registrar may assign less TRUUs than requested (as a matter of local policy), but not more. The UA MAY add a 'truu-expires' parameter to a Contact header for which it requests a TRUU, indicating the desired lifetime for the issued TRUU(s) (in seconds). The value MUST NOT be '0', it is RECOMMENDED to not use values below '180' (i.e. 3 minutes). This parameter provides a hint to the proxy that issues the TRUU, but does not guarantee that the issued TRUU will have the requested lifetime. If a UA instance is requesting a TRUU and registers against multiple AoRs, it SHOULD request TRUUs for each AoR / Contact. Besides the procedures discussed above, the REGISTER request is constructed identically to the case where this extension was not understood. 7.1.2. Processing the REGISTER Response The UA SHOULD verify that the response comes from a trusted source. If the response is a 2xx, it may contain Indirect-Contact headers. These headers contain a SIP or SIPS URIs that represent TRUUs corresponding to the contacts which the UA included in the REGISTER van Bemmel Expires November 13, 2006 [Page 16] Internet-Draft TRUU Mechanism May 2006 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. A different TRUU will be returned 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. A UA MUST ignore any Indirect-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 using the indicated Contact address. 7.1.3. Invalidating a TRUU A UA MAY explicitly invalidate a TRUU. To do so, it formulates a REGISTER request containing an Indirect-Contact header for each TRUU it wishes to invalidate (i.e. cause it to expire). Each such header MUST have an 'expires' parameter with a value of '0', and a 'grid' parameter with a value matching the one that was used when the TRUU was requested. The request MUST have a 'Require: truu' header. It MAY contain Contact headers to install, refresh or expire a subscription. New TRUUs MAY be requested for such Contacts. van Bemmel Expires November 13, 2006 [Page 17] Internet-Draft TRUU Mechanism May 2006 8. Registrar REGISTER Behavior 8.1. Processing the REGISTER Request When a registrar compliant with this specification receives a REGISTER request, it MUST check if the request contains a Require header with a value of 'truu'. If not, it MUST continue processing as it would have done without this specification. The registrar SHOULD authenticate and authorize the requester. A registrar MAY create a TRUU for a particular contact at any time. Of course, if a UA requests a TRUU in a registration, and the registrar has not yet created one, it will need to do so in order to add it to the registration response. However, the registrar can create the TRUU in advance of any request from a UA, as long as it maps to the correct Contact address. A registrar MUST create both the SIP and SIPS versions of the TRUU, such that if the TRUU exists, both URIs exist. A TRUU issued by the registrar 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 registrar is able to determine that the contact will be unreachable (e.g. because the transport is not supported by the registrar and/or the last element on the route) it MUST NOT issue the TRUU, but instead MUST respond with a '501 Transport not implemented'. The registrar MUST check if the request contains any Indirect-Contact headers. If so, and the header contains a TRUU that the registrar recognizes and an expires parameter with a value of '0', it MUST invalidate the TRUU. The way in which this is done is implementation specific. 8.2. Constructing the REGISTER 2xx response When constructing a 2xx response for a REGISTER request which contained one or more Contact headers with a 'trid' parameter, the registrar SHOULD include one or more corresponding Indirect-Contact headers for each such Contact. Each Indirect-Contact MUST contain a TRUU associated with the Contact. The 'trid' parameter in each Indirect-Contact MUST match the 'trid' value of the corresponding Contact header found in the REGISTER request; any 'trid' parameter found in Contact headers MUST be echoed in the Contact header in the response. The expiration time of each issued TRUU is selected based on local policy, the registrar MAY use the value found in a 'truu- expires' parameter in the Contact. The number of Indirect-Contact headers with a TRUU for a given Contact header is chosen based on van Bemmel Expires November 13, 2006 [Page 18] Internet-Draft TRUU Mechanism May 2006 local policy. It MUST be between '1' and the value of the 'truu- count' parameter (if present), it MUST be 1 if this parameter is not present. The registrar SHOULD add authentication / authorization information to the response, to enable the UAC to verify its identity. van Bemmel Expires November 13, 2006 [Page 19] Internet-Draft TRUU Mechanism May 2006 9. Using the TRUU 9.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. This TRUU SHOULD NOT be expired and SHOULD NOT expire within a very short period of time (a minimum of 5 seconds is RECOMMENDED). Note that in some cases the UA may not be aware of TRUU expiry, hence this requirement is not a 'MUST'. When the UA uses a TRUU in a request, it MUST use one corresponding to - i.e. having a hostname that either matches or resolves to the same IP address - an element that is in the route set for that request. It MUST add a Require header with a value of 'truu'. The UA SHOULD add a Proxy-Require header with a value of 'hide-ip', and SHOULD use the host part of the TRUU when populating the sent-by host part 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 a TRUU as a remote target. TBD: How would proxy support for 'hide-ip' be detected? Should it be dynamic, e.g. as part of the registration process, perhaps as part of the URI in a Service-Route? A request using a TRUU may fail because the TRUU is invalid or has expired. The UAC may not always be aware of this, since explicit expiry may happen outside its control (e.g. as the result of network policy). Therefore, when a 435 response is received, the UAC SHOULD obtain a fresh TRUU, and retry the request. When the UA uses a TRUU in a response, it MUST use one that was obtained from an element that is in the route set of the received request (i.e. either in a Record-Route header value in the request or in the route set of the dialog on which the request was received). If the route set is empty, the UA MUST NOT use a TRUU. Note that the UA MUST NOT add a Require header with a value of 'truu', since the registrar will not be able to respond with an error in case the TRUU is invalid or expired. If the UA has no TRUU that matches an element in the route set, it MAY obtain one before responding with a dialog- creating response. For an INVITE request, it SHOULD send a '100 Trying' response before doing this, containing no Contact header or to-tag. [TBD: Any reasonable cases for non-INVITE here?] van Bemmel Expires November 13, 2006 [Page 20] Internet-Draft TRUU Mechanism May 2006 In case the UA can choose amongst multiple TRUUs, it SHOULD prefer TRUUs with a longer remaining lifetime. Note: Possible reasons for using a TRUU with a shorter remaining lifetime include correlation avoidance, or a desire for a particular expiration time. It is RECOMMENDED to use a different TRUU for each dialog. The UA MAY add a 'transport' parameter to the TRUU, corresponding to the transport on which it desires to receive requests targeted at the TRUU. The UA MAY add a 'grid' parameter to the TRUU as described in [5]. This parameter will be present in the request URI of any requests received via the TRUU. The value of this parameter SHOULD NOT be correlated to values used in different dialogs. It is RECOMMENDED to use at least 32 bits of randomness to construct a 'grid' value. The UA MUST NOT use a TRUU obtained through registration against one AoR in a request or response sent in association with another AoR. 9.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 GRUU. A UA MAY interpret the presence of the 'gruu' parameter as an indication of global routability, but SHOULD expect that any request targeted to a URI could fail as a consequence of TRUU expiry. 9.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, possibly including a 'grid' parameter with a token value that the UA can use to distinguish amongst various Contacts it used. A request sent to a TRUU will commonly 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 November 13, 2006 [Page 21] Internet-Draft TRUU Mechanism May 2006 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 newly established dialog. 9.4. Proxy Behavior Proxy behavior is fully defined in Section 16 of RFC 3261. TRUU processing impacts that processing in several places - Request processing and targeting, and response forwarding. 9.4.1. Request Processing 9.4.1.1. IP address hiding When a proxy receives a request containing a Proxy-Require header with an option value of 'hide-ip', it MUST check that there is at least 1 Via header and that the sent-by value in the top Via header is a hostname; if not, it MUST respond with a '400 Bad Request'. Else, the proxy MUST remember the IP address from which the request was received, and add a 'received' parameter with one of its own IP addresses (TBD or perhaps a random 32-bit value converted into IP address format? or something in the 10.x.x.x range?). It SHOULD remove the Proxy-Require value of 'hide-ip'. It MUST forward the request transaction statefully. Note that this via-stripping functionality is a subset of the 'header' privacy offered by [4]. It is included here to allow the use of an identity service hosted by the UAC itself. In principle it is orthogonal to the use of TRUUs, but there are several use cases for which both functions are required. Note that also other proxies could make use of this feature tag, not only UEs. They should only do this when they are able to determine that the next element supports it, and that it is not the final destination of the request. In such a case it should not remove 'hide-ip' when forwarding. Proxies should probably use something like 'hidden.invalid' as a sent-by value, TBD. 9.4.1.2. TRUU issuing proxy (registrar) When a registrar receives a non-REGISTER request from a UA containing a Require header with an option value of 'truu' it MUST check if there is a Contact header which contains a TRUU that is still valid van Bemmel Expires November 13, 2006 [Page 22] Internet-Draft TRUU Mechanism May 2006 (i.e. is recognized as a TRUU issued by this element and has not expired). If it does not recognize the URI as a TRUU it issued, it MUST respond with a '400 Bad TRUU Contact'. If it has expired or is about to expire (this "safe interval" is implementation defined, a value of at least 5 seconds is RECOMMENDED), the proxy MUST generate a '435 TRUU Expired' response and send that. When forwarding, the registrar/proxy MUST remove any Require headers with a value of 'truu'. It MUST Record-Route dialog-creating requests (including unknown methods). 9.4.2. Request Targeting When a proxy 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 acts as if a '503 Service Unavailable' response was received. In particular, it MUST send a 503 error response. This response SHOULD be constructed in such a way that the sender of the request cannot distinguish it from a response resulting from a transport error. If the TRUU does exist and is not expired, the request target MUST be obtained by taking the corresponding contact URI, adding any 'grid' parameter contained in the request URI of the incoming request. The result MUST be used as request URI for the forwarded request. [TBD add a mechanism to guard against peers not adding the 'grid' parameter?] A proxy MAY apply other processing to the request, such as execution of called party features. A request sent to a TRUU MUST NOT be forwarded to more than one destination, and SHOULD NOT be redirected. 9.4.3. Record Routing A registrar / proxy compliant with this specification MUST insert a Record-Route header in every dialog creating request that contains a Contact header with a TRUU issued by the proxy and a Require header with a value of 'truu' (outgoing requests). It SHOULD Record-Route requests targeted at an AoR for which TRUUs have been requested. It SHOULD Record-Route any mid-dialog requests with a request URI that matches a TRUU it issued. Note that these will likely be ignored by the UAS, except e.g. in case of NOTIFYs resulting from forked SUBSCRIBE requests). van Bemmel Expires November 13, 2006 [Page 23] Internet-Draft TRUU Mechanism May 2006 9.4.4. Response Forwarding The following addition is made to step 9 "Response Forwarding" in RFC3261 [2] section 16.7, as a "feature specific manipulation" of the response: The proxy MUST inspect the 'received' parameter. If it is present and matches(*) a value previously inserted by this proxy as a result of IP address hiding, the proxy MUST replace it with the original IP address. (*)Implementation note: It is RECOMMENDED to associate this state (i.e. the original IP address) with the transaction. Implementations must ensure that this functionality does not break spiraling. In particular, the matching mentioned above SHOULD be done by checking local state, and NOT using the equivalent of "if ( received == IP address of this proxy ) then { assume it was doing IP hiding }" A registrar MAY validate a TRUU found in a Contact header in a response, i.e. check that it is recognized and not expired. However, since it cannot respond to a response, it cannot signal the responding UAS of any failure. TBD: do we need a mechanism for this case? van Bemmel Expires November 13, 2006 [Page 24] Internet-Draft TRUU Mechanism May 2006 10. Grammar This specification defines a new header field, Indirect-Contact, two SIP option tags, 'truu' and 'hide-ip', and a new response code, '435 TRUU Expired'. truu-tag = "truu" hide-ip-tag = "hide-ip" Indirect-Contact = "Indirect-Contact" HCOLON (name-addr / addr-spec) *( SEMI ic-param ) ic-param = trid-param / c-p-expires / generic-param trid-param = "trid" EQUAL token truu-expires = "truu-expires" EQUAL delta-seconds truu-count = "truu-count" EQUAL 1*DIGIT ; this definition extends the one from RFC3261: contact-param /= truu-expires / trid-param / truu-count van Bemmel Expires November 13, 2006 [Page 25] Internet-Draft TRUU Mechanism May 2006 11. Requirements This specification was created in order to meet the following requirements: REQ 1: It MUST be possible for the UA to acquire an arbitrary number of distinct URIs, each with an arbitrary bounded lifetime, which indirectly route to a Contact address that belongs to the UA. For the remainder of this section, such URIs will be referred to as "TRUUs" (as a concept, not necessarily referring to the solution presented in this draft). REQ 2: There MUST NOT be any correlation between different TRUUs in anything but the URI scheme, domain, transport parameter, user parameter and gruu flag. REQ 3: When a TRUU which has not expired is invoked, it MUST cause the request to be routed to the specific UA contact address to which the TRUU refers. REQ 4: When a TRUU has expired, any requests routed to it MUST NOT be routed to the UA Contact to which it refers. Instead, such requests MUST either receive an error response from a proxy, or be discarded. REQ 5: It MUST be possible for the UA to acquire a TRUU that is globally routable. REQ 6: It MUST be possible for the UA to determine to which TRUU an incoming request was originally sent. REQ 7: A TRUU SHOULD NOT be distinguishable from any other URI having the GRUU property. REQ 8: A TRUU MAY contain identifying information about the user (e.g. AoR), but it SHOULD be cryptographically hard to retrieve this information. REQ 9: It MUST be possible for the UA to explicitly cause a TRUU to expire. Note that it is NOT a requirement for a proxy to do the reverse mapping, i.e. given a Contact, return all non-expired TRUUs that are currently associated with it. This would unduly constrain solutions. van Bemmel Expires November 13, 2006 [Page 26] Internet-Draft TRUU Mechanism May 2006 11.1. Discussion The 'limited lifetime' property effectively bounds the risk associated with exposing a Contact address. The 'indirect routability' property provides protection against DoS (flooding) attacks, in particular when combined with the ability to explicitly expire a TRUU (e.g. when under attack). As a consequence of the limited lifetime, subsequently issued TRUUs must be different. The 'non-correlation' requirement ensures that they are sufficiently different, such that the other party cannot determine whether two calls come from the same caller, or are answered by the same callee. Some architectures may have the requirement that other elements within the same domain also need access to the TRUU mapping information. Such requirements and their corresponding solutions are considered out of scope for this draft. van Bemmel Expires November 13, 2006 [Page 27] Internet-Draft TRUU Mechanism May 2006 12. 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 and the registrar support the TRUU extension. The REGISTER (1) request to obtain a TRUU looks like: van Bemmel Expires November 13, 2006 [Page 28] Internet-Draft TRUU Mechanism May 2006 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 To: Callee Supported: path Require: truu Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3 CSeq: 1 REGISTER Contact: ;trid=1;expires=3600 ;truu-expires=300 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 Require: truu Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3 CSeq: 1 REGISTER Contact: ;trid=1;expires=3600 Indirect-Contact: ;trid=1;expires=300 Note how the Indirect-Contact header field in the REGISTER response contains the TRUU (sip:zgheqjk879345@h1.example.com:8898;gruu) with a header parameter 'trid' matching the trid parameter in the Contact supplied by the UAC. This TRUU translates to the contact address of 192.0.2.3:5060 (using some internal mapping mechanism, outside the scope of this specification). The proxy selected an expiration interval equal to the requested interval, this is not mandatory. The INVITE from the caller is a normal SIP INVITE sent to sip:callee@example.com. The 200 OK generated by the callee (message 5), however, now contains a TRUU as the remote target (in the Contact header). Note that a 'grid' parameter is added by the callee UAS. van Bemmel Expires November 13, 2006 [Page 29] Internet-Draft TRUU Mechanism May 2006 SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 received=192.0.2.2 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a received=192.0.2.1 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:192.0.2.1 SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKe98a Via: SIP/2.0/UDP h1.example.com:5060;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 Notice how the callee UAC takes care not to reveal any information that would expose its Contact address. The Via sent-by is set to the host part of the TRUU (by the UAC, though it uses its own port), and the proxy appends its own IP address in the 'received' parameter. The UAC included a Proxy-Require: hide-ip in its BYE request (9), but this is not visible to the receiver (caller) because the proxy removed it. The callee decides to explicitly invalidate its TRUU using a REGISTER (13) which looks like: van Bemmel Expires November 13, 2006 [Page 30] Internet-Draft TRUU Mechanism May 2006 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.3;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Callee ;tag=a73xyzwq To: Callee Supported: path Require: truu Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3 CSeq: 123 REGISTER Indirect-Contact: ;trid=1;expires=0 Note how the callee decides not to refresh its registration, although it could have done so (not refreshing it avoids a 'refreshed' registration state event, if any). In many cases it would make sense for the UAC to request a fresh TRUU for the Contact; in that case the refresh is unavoidable. The registrar's response (14) would be: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.3;branch=z9hG4bKnashds8 From: Callee ;tag=a73xyzwq To: Callee ;tag=kjsd09 Supported: path Require: truu Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3 CSeq: 123 REGISTER Contact: ;trid=1;expires=3180 Indirect-Contact: ;trid=1;expires=0 The registrar includes the (still) registered contact, with a matching 'trid' and the current expiration time. It echoes the now- expired TRUU. van Bemmel Expires November 13, 2006 [Page 31] Internet-Draft TRUU Mechanism May 2006 13. Open Issues o Should there be some mechanism to protect against peers removing the 'grid' URI parameter? o Are there any undesired interactions with outbound? o Any point in proxies using 'hide-ip' themselves? Comments are solicited and should be addressed to the SIP working group's mailing list at sip@ietf.org and/or the author(s). van Bemmel Expires November 13, 2006 [Page 32] Internet-Draft TRUU Mechanism May 2006 14. Change history 14.1. -01 to -02 o Added more use cases o Removed 'restricted TRUUs': these would be used to only allow in- dialog usage, but the same can be achieved with rejecting undesired out-of-dialog usages of global TRUUs. Restricted TRUUs can cause things to fail in all sorts of interesting ways, none of which are easily explained to users o Added 'truu-count' for bulk requesting a series of TRUUs o Separated 'truu' from 'hide-ip' o Moved TRUU issueing from first hop proxy to registrar: works better in many cases (including outbound, services offered by home proxies) and requires fewer kludges van Bemmel Expires November 13, 2006 [Page 33] Internet-Draft TRUU Mechanism May 2006 15. Security Considerations It is recommended that the UA use an integrity protected transport towards the first proxy. In many cases, the use of confidentiality mechanisms is also applicable. Obtaining a TRUU has the same security considerations as registration of a Contact. In particular, a registrar SHOULD authenticate and authorize the requester, and SHOULD NOT issue a TRUU in anything except a 2xx response to a REGISTER. The UAC SHOULD authenticate the registrar. The ability to explicitly invalidate a TRUU presents an opportunity for Denial-Of-Service (DoS). An attacker could invalidate a TRUU to prevent requests from arriving at the corresponding Contact. TBD mitigate this risk? van Bemmel Expires November 13, 2006 [Page 34] Internet-Draft TRUU Mechanism May 2006 16. IANA Considerations TBD van Bemmel Expires November 13, 2006 [Page 35] Internet-Draft TRUU Mechanism May 2006 17. Acknowledgements Large portions of this work are based on GRUU [5] and Privacy related issues [9]. The author acknowledges the authors and contributors of those documents. The following persons have provided useful comments (in no particular order): Jesus Javier Arauz, Paul Kyzivat, and Jonathan Rosenberg. 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 November 13, 2006 [Page 36] Internet-Draft TRUU Mechanism May 2006 18. References 18.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] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-07 (work in progress), May 2006. 18.2. Informative References [6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [8] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", draft-ietf-sipping-consent-framework-04 (work in progress), March 2006. [9] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. [10] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-03 (work in progress), March 2006. [11] Sparks, R., "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-06 (work in progress), March 2006. [12] Rosenberg, J., "Identity Privacy in the Session Initiation van Bemmel Expires November 13, 2006 [Page 37] Internet-Draft TRUU Mechanism May 2006 Protocol (SIP)", draft-rosenberg-sip-identity-privacy-00 (work in progress), July 2005. van Bemmel Expires November 13, 2006 [Page 38] Internet-Draft TRUU Mechanism May 2006 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 November 13, 2006 [Page 39] Internet-Draft TRUU Mechanism May 2006 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 (2006). 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 November 13, 2006 [Page 40]