Internet DRAFT - draft-jbemmel-sip-truu
draft-jbemmel-sip-truu
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: <sips:truu1@proxy.example.com;gruu>
...
F5 REFER Transferor -> Transfer Target (using TRUU)
Refer-To: <sips:truu1@proxy.example.com;gruu?Replaces=....>
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 <contact> 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 <contact> 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 <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com>
Supported: path
Require: truu
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3
CSeq: 1 REGISTER
Contact: <sip:callee@192.0.2.3>;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 <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com>;tag=b88sn
Supported: path
Require: truu
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3
CSeq: 1 REGISTER
Contact: <sip:callee@192.0.2.3>;trid=1;expires=3600
Indirect-Contact: <sip:zgheqjk879345@h1.example.com:8898;gruu>
;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 <sip:caller@example.com>;tag=n88ah
To: Callee <sip:callee@example.com>;tag=a0z8
Call-ID: 1j9FpLxk3uxtma7@192.0.2.1
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK
Contact: <sip:zgheqjk879345@h1.example.com:8898;gruu;grid=jhsd98>
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 <sip:callee@example.com>;tag=a0z8
To: Caller <sip:caller@example.com>;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 <sip:callee@example.com>;tag=a73xyzwq
To: Callee <sip:callee@example.com>
Supported: path
Require: truu
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3
CSeq: 123 REGISTER
Indirect-Contact: <sip:zgheqjk879345@h1.example.com:8898;gruu>
;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 <sip:callee@example.com>;tag=a73xyzwq
To: Callee <sip:callee@example.com>;tag=kjsd09
Supported: path
Require: truu
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.3
CSeq: 123 REGISTER
Contact: <sip:callee@192.0.2.3>;trid=1;expires=3180
Indirect-Contact: <sip:zgheqjk879345@h1.example.com:8898;gruu>
;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]
