Subject: [Sip] GRUU corner cases

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Dec 2003 19:03:45 -0500

GRUU is looking pretty good. As I'm reading thru it I am thinking about 
weird corner cases that might be underspecified.

Suppose one UA registers its own contact without requesting a GRUU:

	REGISTER sip:example.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Expires: 3600
	Contact: sip:[email-masked]
	Call-Id: [email-masked]

Then, another UA queries this registration, and then sends its own 
update to it, requesting a gruu:

	REGISTER sip:example.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Supported: gruu
	Expires: 3600
	Contact: sip:[email-masked];gruu
	Call-Id: [email-masked]

(Assume this is properly authenticated and authorized.) Is this ok?

Then while that registration is still active, suppose there is yet 
another one:

	REGISTER sip:example.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Supported: gruu
	Expires: 3600
	Contact: sip:[email-masked];gruu
	Call-Id: [email-masked]

Is that legal too? If so, it could result in the same gruu being given 
to bar and baz. Is it also ok to give different ones to each? If 
different ones, does issuing the new one to baz invalidate the one given 
to bar?

In this specific case it probably isn't important what happens. But in 
general it will be hard for the registrar to distinguish bizare cases 
like this from more normal cases where things ought to work. In 
particular, can a registration that doesn't appear to be a refresh 
invalidate a previously issued gruu?

I think the current intent is that the gruu is required to stick with a 
particular contact address as long as that is registered, regardless of 
whether the refresh is technically a refresh from the same source and 
callid or not. If so, then everybody receives the same gruu. That is 
probably ok. If so, continuing the above scenario, suppose the original 
ua now refreshes:

	REGISTER sip:example.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Expires: 3600
	Contact: sip:[email-masked]
	Call-Id: [email-masked]

MUST/SHOULD/MAY the Contact header in the response contain the gruu= 
parameter? My opinion is that it SHOULD.

What about the "reg" event package? If a gruu is associated with a 
particular contact, is that reported in notifications? Does it matter 
whether the subscriber specifes Supported:gruu or not? IMO the gruu MUST 
be included if Supported:gruu is present, and SHOULD be present otherwise.

In section 5:

    ... the GRUU MUST exhibit the
    following properties:

    o  When a request is sent to this URI, it routes to a proxy server in
       the same domain as that of the registrar.

    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
       is equal to the Contact URI corresponding to the GRUU.

    o  It MUST NOT be possible, based on inspection of the URI, to
       determine the associated Contact URI or Address of Record.

This excludes an interesting special case. It is possible that the 
registrar can determine that the contact address being registered is 
already globally routable. If so, it would be good for the registrar to 
have the option of simply returning the contact address as the gruu. The 
above criteria exclude that possibility.

Of course, that would eliminate the privacy advantage of gruus. But we 
already know that is at best limited. In some cases a UA might prefer 
the performance advantage of bypassing the proxy if it isn't needed. 
What about making the requirement to anonymize the gruu an option on the 
REGISTER?

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Dec 2003 10:59:35 -0500

Thanks for your further comments. Inline.

> (Assume this is properly authenticated and authorized.) Is this ok?

Requesting a GRUU would not involve placing the gruu parameter in the 
Contact. Presence of "Supported: gruu" is what triggers this. Thus, 
the contact would just be:

Contact: sip:xyz2a.example.com

Besides that, everything is OK so far.

>     Call-Id: [email-masked]

Same as above - there would not be a gruu parameter in the Contact. In 
this case, the response wouold contain the currently assigned gruu for 
this contact.

> to bar and baz.

Yes. I think this is what you want.

> Is it also ok to give different ones to each? If 

I think the question is, "what is the scope of the gruu"? Is it JUST 
the contact, or is it the combination of the Contact along with the 
call-id, which is used by the registrar to provide a context for 
ordering registrations? i think its just the contact. That is, if a 
different UA (or the same one with a new call-id) refreshes a contact, 
even if the call-id stored by the registrar changes, the gruu remains 
the same.

> invalidate a previously issued gruu?

But, this does appear to be a refresh. Its a refresh because the 
contact exists.

> callid or not.

Correct.

> If so, then everybody receives the same gruu. 

Right.

> That is 

I don't think so. This UA doesnt support GRUU. So, the GRUU exists in 
the registrar; its just not returned to the UA.

I think we need some clarification in the spec to cover these cases. I 
have substantially rewritten the section on registrar processing to 
make this more clear. My new text is below; please comment on whether 
this makes more sense than before - I think its much better now. 
Another point that it clarifies is that the gruu is really associated 
with the AOR/Contact pair, not just the Contact. So, if you register 
the same contact to two different AOR, you get two gruus.

> be included if Supported:gruu is present, and SHOULD be present otherwise.

We could add this as an extension to reg-event, since reg-event is 
done. However, when we do, I dont think that we would use "Supported: 
gruu" to indicate that the gruu should be included in the 
notification. This is a filtering function, and should be done either 
in a body part or though an event header parameter. one thing at a 
time though.

> above criteria exclude that possibility.

Unless the contact being registered is within the domain owned by the 
registrar, the registrar will not have a reliable way of knowing 
whether its globally routable by inspecting the address (even if its a 
public IP, i.e., outside of net-10, 198.162/16, etc., you can't be 
sure). It could presumably run a test, and send an OPTIONS to that 
address from an interface thats known to be on the public Internet. If 
the registrar gets a response to the OPTIONS request, it knows the 
Contact is publically routable.

However, we have also talked about executing features in proxies when 
a request is sent to a gruu (for example, call screening services). 
That capability would be lost. As such, a user would not be able to 
know whether or not server processing has been applied when a request 
arrives, and I think thats a problem.

So, I'm inclined to stick with whats there right now.

> What about making the requirement to anonymize the gruu an option on the 

The problem is that real privacy requires a lot more than just an 
anonymous gruu. There is also masking of varaious header fields, like 
Vias, along with media address hiding.

Here is my proposed new text for the registrar behavior section. 
Please provide comments:

> 5. Registrar Behavior
> 
>    A registrar compliant to this specification is responsible for the
>    creation and maintenance of GRUUs, and for providing those GRUU's to
>    a UA in response to a REGISTER request.
> 
> 5.1 Creation and Maintenance of GRUUs
> 
> 
> 
> 
> Rosenberg                Expires June 10, 2004                  [Page 5]
> 
> Internet-Draft               GRUU Mechanism                December 2003
> 
> 
>    There is a one-to-one mapping between a Contact URI for a particular
>    AOR, and a GRUU. As a result, if two Contact/AOR pairs are different,
>    the GRUU for each MUST be different. If two GRUUs are different, the
>    Contact/AOR pair for those MUST be different. It is important to
>    understand that this uniqueness is over the Contact/AOR pair, not
>    just the Contact. For example, if a user registered the Contact
>    sip:[email-masked] to the AOR sip:[email-masked], and also
>    registered the same Contact - sip:[email-masked] to a second AOR,
>    say sip:[email-masked], each of those Contacts would have a
>    different GRUU, since they belong to different AORs.
> 
>    A registrar MAY create a GRUU for a particular AOR/Contact pair at
>    any time. Of course, if a UA requests a GRUU in a registration, and
>    the registrar has not yet created one, it will need to do so in order
>    to respond to the registration request. However, the registrar can
>    create the GRUU in advance of any request from a UA.
> 
>    This specification does not mandate a particular mechanism for
>    construction of the GRUU. However, the GRUU MUST exhibit the
>    following properties:
> 
>    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
>       corresponds to an IP address present on the public Internet.
> 
>    With these rules, it is possible, though not required, to construct a
>    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)))
> 
>    Where E(K,X) represents a suitable encryption function (such as AES
>    with 128 bit keys) with key K applied to data block X, and the "+"
>    operator implies concatenation. Salt represents a random string that
>    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.
> 
> 
> 
> Rosenberg                Expires June 10, 2004                  [Page 6]
> 
> Internet-Draft               GRUU Mechanism                December 2003
> 
> 
>    The benefit of this mechanism is that a server need not store
>    additional information on mapping a GRUU to its corresponding Contact
>    URI. The user part of the GRUU can itself contain the Contact URI.
>    Encryption is needed to prevent attacks whereby the server is sent
>    requests with faked GRUU, causing the server to direct requests to
>    any named URI. Even with encryption, the proxy should validate the
>    user part after decryption. In particular, the AOR should be one
>    managed by the proxy in that domain. Should a UA send a request with
>    a fake GRUU, the proxy would decrypt and then discard it because
>    there would be no URI or an invalid URI inside.
> 
>    Once created, the registrar MUST maintain that GRUU for the duration
>    over which that Contact remains registered to that AOR at the
>    registrar. Furthermore, the registrar MUST NOT change the gruu during
>    that duration. This is true even if the Contact is refreshed from a
>    rebooted or different UA (known by a change in the Call-ID of the
>    REGISTER request). After the Contact expires, the registrar ceases to
>    maintain the binding. The registrar is under no obligation to use the
>    same GRUU should that Contact be re-registered at a later time. Of
>    course, it MAY create the same GRUU if it likes, but this would be an
>    implementation choice.
> 
>    The implication of these rules is that a registrar is responsible for
>    reliable storage of the GRUU for the duration of a registration.
> 
> 5.2 Providing GRUUs to User Agents
> 
>    When a registrar compliant to this specification receives a REGISTER
>    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 registrar MUST follow the procedures in the next paragraph for
>    inclusion of the "gruu" parameter in a 2xx response to REGISTER. If
>    not present, but a Supported header field was present with the "gruu"
>    option tag, the registrar SHOULD follow the procedures in the next
>    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
>    present but did not contain the value "gruu", the registrar SHOULD
>    NOT follow the procedures of the next paragraph for inclusion of the
>    "gruu" parameter in a 2xx response to REGISTER.
> 
>    If the register request contained any "gruu" Contact header field
>    parameters, these MUST be ignored by the registrar. A UA cannot
>    suggest or otherwise provide a GRUU to the registrar.
> 
>    A GRUU is provided to a UA by including it in the "gruu" Contact
>    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/AOR pair. If the server does not
> 
> 
> 
> Rosenberg                Expires June 10, 2004                  [Page 7]
> 
> Internet-Draft               GRUU Mechanism                December 2003
> 
> 
>    currently have a GRUU associated with the Contact URI, either because
>    the Contact URI is being newly registered, or because it is being
>    refreshed, but the registrar has not yet computed a GRUU for that
>    Contact, one is created according to the procedures of Section 5.1.
>    Otherwise, if a GRUU already exists for that AOR/Contact pair, the
>    GRUU associated with that pair MUST be placed into the "gruu" Contact
>    header field parameter of the REGISTER response.
> 
>    Inclusion of a GRUU in the "gruu" Contact header field parameter of a
>    REGISTER response is separate from the computation and storage of the
>    GRUU. It is possible that the registrar has computed a GRUU for a
>    contact at the request of one UA, but a different UA that queries for
>    the current set of registrations doesn't understand GRUU. In that
>    case, the REGISTER response sent to that second UA would not contain
>    the "gruu" Contact header field parameter, even though the UA has a
>    GRUU for that Contact.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com