< draft-rosenberg-sip-gruu-00.txt   draft-rosenberg-sip-gruu-01.txt >
SIP J. Rosenberg SIP J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: April 19, 2004 October 20, 2003 Expires: June 4, 2004 December 5, 2003
Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in
the Session Initiation Protocol (SIP) the Session Initiation Protocol (SIP)
draft-rosenberg-sip-gruu-00 draft-rosenberg-sip-gruu-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2004. This Internet-Draft will expire on June 4, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Several applications of the Session Initiation Protocol (SIP) require Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI which can be used a user agent (UA) to construct and distribute a URI which can be used
by anyone on the Internet to route a call to that specific UA by anyone on the Internet to route a call to that specific UA
skipping to change at page 2, line 12 skipping to change at page 2, line 12
to SIP for obtaining a GRUU from a server, and for communicating a to SIP for obtaining a GRUU from a server, and for communicating a
GRUU to a peer within a dialog. GRUU to a peer within a dialog.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . 3 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 4 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 4
4.1 REGISTER Processing . . . . . . . . . . . . . . . . . . . . 4 4.1 REGISTER Processing . . . . . . . . . . . . . . . . . . . . 4
4.2 Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . 5
5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . 5 5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . 5
6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
10.1 Header Field Parameter . . . . . . . . . . . . . . . . . . . 12 10.1 Header Field Parameter . . . . . . . . . . . . . . . . . . . 12
10.2 URI Parameter . . . . . . . . . . . . . . . . . . . . . . . 12 10.2 URI Parameter . . . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . 15
1. Introduction 1. Introduction
Several applications of the Session Initiation Protocol (SIP) [1] Several applications of the Session Initiation Protocol (SIP) [1]
require a user agent (UA) to construct and distribute a URI which can require a user agent (UA) to construct and distribute a URI which can
be used by anyone on the Internet to route a call to that specific UA be used by anyone on the Internet to route a call to that specific UA
instance. An example of such an application is call transfer, based instance. An example of such an application is call transfer, based
on the REFER method [4]. Another application is the usage of on the REFER method [4]. Another application is the usage of
endpoint-hosted conferences within the conferencing framework [7]. endpoint-hosted conferences within the conferencing framework [8].
We call these URIs Globally Routable UA URIs (GRUU). Requirements [8] We call these URIs Globally Routable UA URIs (GRUU). Requirements [9]
have been defined which identify the capabilities that any mechanism have been defined which identify the capabilities that any mechanism
for obtaining and using a GRUU has to provide. This specification for obtaining and using a GRUU has to provide. This specification
describes a mechanism that meets these requirements. describes a mechanism that meets these requirements.
2. Overview of Operation 2. Overview of Operation
This section is tutorial in nature, and does not specify any This section is tutorial in nature, and does not specify any
normative behavior. normative behavior.
This extension allows a UA to obtain a GRUU, and to use a GRUU. These This extension allows a UA to obtain a GRUU, and to use a GRUU. These
skipping to change at page 3, line 35 skipping to change at page 3, line 35
way it likes, and use the mechanisms in this specification to use way it likes, and use the mechanisms in this specification to use
them. Similarly, a UA can obtain a GRUU but never use it. them. Similarly, a UA can obtain a GRUU but never use it.
A UA can obtain a GRUU by generating a normal REGISTER request, as A UA can obtain a GRUU by generating a normal REGISTER request, as
specified in RFC 3261 [1]. This request contains a Supported header specified in RFC 3261 [1]. This request contains a Supported header
field with the value "gruu", indicating to the registrar that the UA field with the value "gruu", indicating to the registrar that the UA
supports this extension. If the domain that the user is registering supports this extension. If the domain that the user is registering
against also supports GRUU, the REGISTER responses will contain the against also supports GRUU, the REGISTER responses will contain the
"gruu" parameter in each Contact header field. This parameter "gruu" parameter in each Contact header field. This parameter
contains a GRUU which the domain guarantees will route to that contains a GRUU which the domain guarantees will route to that
specific Contact URI. specific Contact URI. That GRUU is guaranteed to remain valid for the
duration of the registration.
Since the GRUU is a URI like any other, it can be handed out by a UA Since the GRUU is a URI like any other, it can be handed out by a UA
by placing it in any header field which can contain a GRUU. A UA will by placing it in any header field which can contain a GRUU. A UA will
normally place the GRUU into the Contact header field of dialog normally place the GRUU into the Contact header field of dialog
creating requests and responses it generates. However, it is creating requests and responses it generates. However, it is
important for the UA receiving the message to know whether the important for the UA receiving the message to know whether the
Contact URI is a GRUU or not. To make this determination, the UA Contact URI is a GRUU or not. To make this determination, the UA
looks for the presence of the Supported header field in the request looks for the presence of the Supported header field in the request
or response. If it is present with a value of "gruu", it means that or response. If it is present with a value of "gruu", it means that
the Contact URI is a GRUU. the Contact URI is a GRUU.
skipping to change at page 4, line 29 skipping to change at page 4, line 30
When a UA wishes to obtain a GRUU within the domain of its AOR, when When a UA wishes to obtain a GRUU within the domain of its AOR, when
it generates a REGISTER request (initial or refresh), it MUST include it generates a REGISTER request (initial or refresh), it MUST include
the Supported header field in the request. The value of that header the Supported header field in the request. The value of that header
field MUST include "gruu" as one of the option tags. This alerts the field MUST include "gruu" as one of the option tags. This alerts the
registrar for the domain that the UA supports the GRUU mechanism. registrar for the domain that the UA supports the GRUU mechanism.
Besides the presence of this option tag in the Supported header Besides the presence of this option tag in the Supported header
field, the REGISTER request is constructed identically to the case field, the REGISTER request is constructed identically to the case
where this extension was not understood. Specifically, the Contact where this extension was not understood. Specifically, the Contact
URI in the REGISTER request SHOULD NOT contain the gruu Contact URI in the REGISTER request SHOULD NOT contain the gruu Contact
header field parameter. header field parameter. Any such parameters are ignored by the
registrar, as the UA cannot propose a GRUU for usage with the Contact
URI.
If a UA wishes to guarantee that the request is not processed unless If a UA wishes to guarantee that the request is not processed unless
the domain supports and uses this extension, it MAY include a Require the domain supports and uses this extension, it MAY include a Require
header field in the request with a value that contains the "gruu" header field in the request with a value that contains the "gruu"
option tag. option tag.
If the response is a 2xx, each Contact header field may contain a If the response is a 2xx, each Contact header field may contain a
"gruu" parameter. This parameter contains a SIP URI that represents a "gruu" parameter. This parameter contains a SIP URI that represents a
GRUU corresponding to that Contact URI. Any requests sent to the GRUU GRUU corresponding to that Contact URI. Any requests sent to the GRUU
URI will be routed by the domain to the Contact URI. URI will be routed by the domain to the Contact URI. The GRUU will
not change in subsequent 2xx responses to REGISTER as long as the UA
does not let the registration expire. However, if the UA waits until
the last moment to refresh its registration, it may cause a race
condition where the registration expires while the registration is in
transit. The resulting 200 OK might then contain a different GRUU.
Since "last moment" is ill defined, it is RECOMMENDED that a UA be
prepared to handle a change in the GRUU during a registration.
Handling a change depends on the way in which it has been used. In
the case where it is included in the Contact URI of a dialog
initiating request or response, the UA would update the Contact URI
with a target refresh request.
4.2 Using the GRUU 4.2 Using the GRUU
A UA first obtains a GRUU. It can do this using the procedures of A UA first obtains a GRUU using the procedures of Section 4.1.
Section 4.1, or, in cases where the UA is certain that it can locally
construct a URI meeting the properties of Section 4.1, it can
construct one using its own IP address or host name as the domain
part. However, local construction of a GRUU is NOT RECOMMENDED, since
it is hard for a UA to generally know whether its IP address is
globally routable.
OPEN ISSUE: Another option is to use session independent policies
[9] to inform a UA about whether it needs to obtain a GRUU from
the provider, or whether it is safe to try and construct one on
its own. It may still be hard for the provider to determine
whether or not the UA can use a locally generated GRUU.
A UA can use the GRUU in the same way it would use any other SIP URI. A UA can use the GRUU in the same way it would use any other SIP URI.
However, a UA compliant to this specification MUST use a GRUU when However, a UA compliant to this specification MUST use a GRUU when
populating the Contact header field of dialog-creating requests and populating the Contact header field of dialog-creating requests and
responses. This includes the INVITE request and its 2xx response, the responses. This includes the INVITE request and its 2xx response, the
SUBSCRIBE [3] request, its 2xx response, and the NOTIFY request, and SUBSCRIBE [3] request, its 2xx response, and the NOTIFY request, and
the REFER [4] request and its 2xx response. Similarly, in those the REFER [4] request and its 2xx response. Similarly, in those
requests and responses where the GRUU is used in the Contact header requests and responses where the GRUU is used in the Contact header
field, the UA MUST include a Supported header field that contains the field, the UA MUST include a Supported header field that contains the
option tag "gruu". However, it is not necessary for a UA to know option tag "gruu". However, it is not necessary for a UA to know
skipping to change at page 5, line 34 skipping to change at page 5, line 34
response, a UA MAY add the "grid" URI parameter to the GRUU. This response, a UA MAY add the "grid" URI parameter to the GRUU. This
parameter MAY take on any value permitted by the grammar for the parameter MAY take on any value permitted by the grammar for the
parameter, but MUST NOT exceed 128 characters. When a UA sends a parameter, but MUST NOT exceed 128 characters. When a UA sends a
request to the GRUU, the proxy for the domain that owns the GRUU will request to the GRUU, the proxy for the domain that owns the GRUU will
copy this parameter from the GRUU into the Contact URI matching that copy this parameter from the GRUU into the Contact URI matching that
GRUU. This allows the UA to effectively manufacture an infinite GRUU. This allows the UA to effectively manufacture an infinite
supply of GRUU, each of which differs by the value of the "grid" supply of GRUU, each of which differs by the value of the "grid"
parameter. When a UA receives a request that was sent to the GRUU, it parameter. When a UA receives a request that was sent to the GRUU, it
will be able to tell which GRUU was invoked by the "grid" parameter. will be able to tell which GRUU was invoked by the "grid" parameter.
When a UA (UA 1) wishes to generate a request to another UA, UA 2, An implication of this behavior is that all mid-dialog requests will
and UA 1 and UA 2 are involved in an active dialog, and the request be routed through intermediate proxies. There will never be direct,
is not associated with the existing dialog, and UA 2 indicated UA to UA signaling. It is anticipated that this limitation will be
support for this extension, UA 1 SHOULD send the request to the addressed in future specifications.
remote target URI if UA 2. Examples of such requests are SUBSCRIBE
and REFER. Currently, RFC 3261 describes the notion of dialog Once a UA knows that the Contact URI provided by its peer is a GRUU,
sharing, which would advocate generation of these requests within the it can use it in any application or SIP extension which requires a
context of the existing dialog. This specification supercedes that globally routable URI to operate. One such example is assisted call
behavior. In cases where UA 1 wishes to send the request, but UA 2 transfer.
has not indicated support for GRUU, UA 1 SHOULD send the request on
the existing dialog.
5. Registrar Behavior 5. Registrar Behavior
When a registrar compliant to this specification receives a REGISTER When a registrar compliant to this specification receives a REGISTER
request, it checks for the presence of the Require header field in request, it checks for the presence of the Require header field in
the request. If present, and if it contains the "gruu" option tag, the request. If present, and if it contains the "gruu" option tag,
the registrar MUST follow the procedures in the next paragraph for the registrar MUST follow the procedures in the next paragraph for
inclusion of the "gruu" parameter in a 2xx response to REGISTER. If inclusion of the "gruu" parameter in a 2xx response to REGISTER. If
not present, but a Supported header field was present with the "gruu" not present, but a Supported header field was present with the "gruu"
option tag, the registrar SHOULD follow the procedures in the next option tag, the registrar SHOULD follow the procedures in the next
paragraph for inclusion of the "gruu" parameter in a 2xx response to paragraph for inclusion of the "gruu" parameter in a 2xx response to
REGISTER. If the Supported header field was not present, or it if was REGISTER. If the Supported header field was not present, or it if was
present but did not contain the value "gruu", the registrar SHOULD present but did not contain the value "gruu", the registrar SHOULD
NOT follow the procedures of the next paragraph for inclusion of the NOT follow the procedures of the next paragraph for inclusion of the
"gruu" parameter in a 2xx response to REGISTER. "gruu" parameter in a 2xx response to REGISTER.
When the registrar generates a 2xx response to the REGISTER request, If the register request contained any "gruu" Contact header field
if it wishes to provide a GRUU to the UA, it includes a "gruu" parameters, these MUST be ignored by the registrar. A UA cannot
Contact header field parameter for each value of the Contact header suggest or otherwise provide a GRUU to the registrar.
field. The value of this parameter is a quoted string containing the
URI that is the GRUU for the associated Contact URI. This A GRUU is provided to a UA by including it in the "gruu" Contact
specification does not mandate a particular mechanism for header field parameter for a particular Contact URI. The value of
this parameter is a quoted string containing the URI that is the GRUU
for the associated Contact URI. If the REGISTER request was
refreshing that Contact URI, and the registrar had provided a gruu to
the UA previously, the registrar MUST include the "gruu" Contact
header field parameter for that Contact URI, and its value MUST
contain the same URI provided previously. The result is that there is
a one to one mapping of a GRUU to a Contact URI for the duration that
the Contact is registered to the UA. Note that, should the
registration of that Contact expire, and then the UA re-registers it
at a later time, the registrar is under no obligation to use the same
GRUU for that Contact URI. The implication of these rules is that a
registrar is responsible for reliable storage of the GRUU for the
duration of a registration.
If the REGISTER request is creating a new Contact URI for a
particular address of record, and the registrar decides to provide
the UA with a gruu for that Contact URI, it constructs a new GRUU.
This specification does not mandate a particular mechanism for
construction of the GRUU. However, the GRUU MUST exhibit the construction of the GRUU. However, the GRUU MUST exhibit the
following properties: following properties:
o The domain part of the URI is an IP address present on the public o The domain part of the URI is an IP address present on the public
Internet, or, if it is a host name, exists in the global DNS and Internet, or, if it is a host name, exists in the global DNS and
corresponds to an IP address present on the public Internet. corresponds to an IP address present on the public Internet.
o When a request is sent to this URI, it routes to a proxy server in o When a request is sent to this URI, it routes to a proxy server in
the same domain as that of the registrar. the same domain as that of the registrar.
o A proxy server in the domain can determine that the URI is a GRUU. o A proxy server in the domain can determine that the URI is a GRUU.
o When a proxy server in this domain translates this URI, the result o When a proxy server in this domain translates this URI, the result
is equal to the Contact URI corresponding to the GRUU. is equal to the Contact URI corresponding to the GRUU.
o It MUST NOT be possible, based on inspection of the URI, to o It MUST NOT be possible, based on inspection of the URI, to
determine the associated Contact URI or Address of Record. determine the associated Contact URI or Address of Record.
One mechanism for constructing this GRUU is to set the user part of With these rules, it is possible, though not required, to construct a
the URI in the following fashion: GRUU without requiring the maintenance of any additional state. To do
that, the URI would be constructed in the following fashion:
user-part = "GRUU" + BASE64(E(K, (salt + Contact URI + AOR))) user-part = "GRUU" + BASE64(E(K, (salt + Contact URI + AOR)))
Where E(K,X) represents a suitable encryption function with key K Where E(K,X) represents a suitable encryption function (such as AES
applied to data block X, and the "+" operator implies concatenation. with 128 bit keys) with key K applied to data block X, and the "+"
Salt represents a random string that prevents a client from obtaining operator implies concatenation. Salt represents a random string that
pairs of known plaintext and ciphertext. prevents a client from obtaining pairs of known plaintext and
ciphertext. A good choice would be at least 128 bits of randomness in
the salt.
The benefit of this mechanism is that a server need not store The benefit of this mechanism is that a server need not store
additional information on mapping a GRUU to its corresponding Contact additional information on mapping a GRUU to its corresponding Contact
URI. The user part of the GRUU can itself contain the Contact URI. URI. The user part of the GRUU can itself contain the Contact URI.
Encryption is needed to prevent attacks whereby the server is sent Encryption is needed to prevent attacks whereby the server is sent
requests with faked GRUU, causing the server to direct requests to requests with faked GRUU, causing the server to direct requests to
any named URI. any named URI. Even with encryption, the proxy should validate the
user part after decryption. In particular, the AOR should be one
OPEN ISSUE: Need some more work on the details of the encryption. managed by the proxy in that domain. Should a UA send a request with
Probably we want to recommend rotating the key. Do we also need a a fake GRUU, the proxy would decrypt and then discard it because
signature? there would be no URI or an invalid URI inside.
6. Proxy Behavior 6. Proxy Behavior
When a proxy server receives a request, and the proxy owns the domain When a proxy server receives a request, and the proxy owns the domain
in the Request URI, and the proxy is supposed to access a Location in the Request URI, and the proxy is supposed to access a Location
Service in order to compute request targets (as specified in Section Service in order to compute request targets (as specified in Section
16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a 16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a
GRUU created by that domain. GRUU created by that domain.
If the URI is a GRUU, the proxy MUST determine if the Contact URI If the URI is a GRUU, the proxy MUST determine if the Contact URI
skipping to change at page 7, line 41 skipping to change at page 8, line 12
of called party features. In particular, it is RECOMMENDED that of called party features. In particular, it is RECOMMENDED that
non-routing called party features, such as call logging and non-routing called party features, such as call logging and
screening, that are associated with the AOR are also applied to screening, that are associated with the AOR are also applied to
requests for the GRUU. requests for the GRUU.
In many cases, a proxy will record-route an initial INVITE request, In many cases, a proxy will record-route an initial INVITE request,
and the user agents will insert a GRUU into the Contact header field. and the user agents will insert a GRUU into the Contact header field.
When this happens, a mid-dialog request will arrive at the proxy with When this happens, a mid-dialog request will arrive at the proxy with
a Route header field that was inserted by the proxy, and a a Route header field that was inserted by the proxy, and a
Request-URI that represents a GRUU. Proxies follow normal processing Request-URI that represents a GRUU. Proxies follow normal processing
this this case; they will strip the Route header field, and then in this case; they will strip the Route header field, and then
process the Request URI as described above. process the Request URI as described above.
The procedures of RFC 3261 are then followed to proxy the request. The procedures of RFC 3261 are then followed to proxy the request.
The request SHOULD NOT be redirected in this case. In many instances,
OPEN ISSUE: Do we allow redirects on a GRUU? Could be bad, if the a GRUU is used by a UA in order to assist in the traversal of NATs,
problem was firewall/NAT traversal in the first place. and a redirection may prevent such a case from working.
7. Grammar 7. Grammar
This specification defines a new Contact header field parameter, This specification defines a new Contact header field parameter,
gruu, and a new URI parameter, grid. gruu, and a new URI parameter, grid.
contact-params = c-p-q / c-p-expires / c-p-gruu contact-params = c-p-q / c-p-expires / c-p-gruu
/ contact-extension / contact-extension
c-p-gruu = "gruu" EQUAL SWS DQUOTE SIP-URI DQUOTE c-p-gruu = "gruu" EQUAL SWS DQUOTE SIP-URI DQUOTE
uri-parameter = transport-param / user-param / method-param uri-parameter = transport-param / user-param / method-param
skipping to change at page 11, line 41 skipping to change at page 11, line 41
Call-ID: faif9a@host.example.com Call-ID: faif9a@host.example.com
CSeq: 2 SUBSCRIBE CSeq: 2 SUBSCRIBE
Supported: gruu Supported: gruu
Event: dialog Event: dialog
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK Allow: INVITE, OPTIONS, CANCEL, BYE, ACK
Contact: <sip:bad998asd8asd0000a0@example.com> Contact: <sip:bad998asd8asd0000a0@example.com>
Content-Length: 0 Content-Length: 0
9. Security Considerations 9. Security Considerations
Users interested in anonymity can make use of GRUUs. Since GRUUs do Since GRUUs do not reveal information about the identity of the
not reveal information about the identity of the associated associated address-of-record or Contact URI, they provide routability
address-of-record or Contact URI, they provide routability without without identity. However, GRUUs do not provide a complete or
identity. reliable solution for privacy. In particular, since the GRUU does not
change during the lifetime of a registration, an attacker could
correlate two calls as coming from the same source, which in and of
itself reveals information about the caller. Furthermore, GRUUs do
not address other aspects of privacy, such as the addresses used for
media transport. For a discussion of how privacy services are
provided in SIP, see RFC 3323 [7].
It is important for a UA to be assured of the integrity of a GRUU It is important for a UA to be assured of the integrity of a GRUU
when it is given one in a REGISTER response. If the GRUU is tampered when it is given one in a REGISTER response. If the GRUU is tampered
with by an attacker, the result could be denial of service to the UA. with by an attacker, the result could be denial of service to the UA.
As a result, it is RECOMMENDED that a UA use the SIPS URI scheme when As a result, it is RECOMMENDED that a UA use the SIPS URI scheme when
registering. registering.
10. IANA Considerations 10. IANA Considerations
This specification defines a new Contact header field parameter and This specification defines a new Contact header field parameter and
skipping to change at page 13, line 17 skipping to change at page 13, line 23
draft-ietf-sip-parameter-registry-00 (work in progress), August draft-ietf-sip-parameter-registry-00 (work in progress), August
2003. 2003.
[6] Camarillo, G., "The Internet Assigned Number Authority Universal [6] Camarillo, G., "The Internet Assigned Number Authority Universal
Resource Identifier Parameter Registry for the Session Resource Identifier Parameter Registry for the Session
Initiation Protocol", draft-ietf-sip-uri-parameter-reg-00 (work Initiation Protocol", draft-ietf-sip-uri-parameter-reg-00 (work
in progress), August 2003. in progress), August 2003.
Informative References Informative References
[7] Rosenberg, J., "A Framework for Conferencing with the Session [7] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[8] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-00 (work in draft-ietf-sipping-conferencing-framework-00 (work in
progress), May 2003. progress), May 2003.
[8] Rosenberg, J., "Requirements for Construction and Usage of [9] Rosenberg, J., "Requirements for Construction and Usage of
Globally Routable User Agent (UA) URIs for the Session Globally Routable User Agent (UA) URIs for the Session
Initiation Protocol (SIP)", Initiation Protocol (SIP)",
draft-rosenberg-sipping-gruu-reqs-00 (work in progress), July draft-rosenberg-sipping-gruu-reqs-01 (work in progress),
2003.
[9] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for
Session-Independent Intermediary Session Policies in SIP",
draft-hilt-sipping-session-indep-policy-00 (work in progress),
October 2003. October 2003.
[10] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog [10] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
Event Package for the Session Initiation Protocol (SIP", Event Package for the Session Initiation Protocol (SIP",
draft-ietf-sipping-dialog-package-02 (work in progress), July draft-ietf-sipping-dialog-package-02 (work in progress), July
2003. 2003.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
 End of changes. 21 change blocks. 
67 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/