Subject: RE: [Sip] Updated GRUU spec - big changes

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 26 Oct 2006 14:58:22 +0200

Just to note that full privacy of GRUUs is not dead.

We agreed on the list some time back, in association with IETF#66, that
the current mechanism of GRUU would not provide this, and in fact in -11
we have put back in more "privacy" than existed in the previous version.

What we agreed is a "do this later". Therefore the WG chairs are
interested in proposals to build GRUU capabilities with full privacy. It
is recognised as something that will take longer, and we may need to
define what full privacy is in respect of SIP first. Start writing those
internet-drafts to cover this. I am aware we already have one author
draft in this area in draft-jbemmel-sip-truu-02 (currently expired).

(People are also welcome to come to a different consensus if they wish
to!!!!)

Regards

Keith

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: 25 October 2006 21:59
> To: Rohan Mahy
> Cc: IETF SIP List
> Subject: Re: [Sip] Updated GRUU spec - big changes
> 
> "Rohan Mahy" <[email-masked]> writes:
> 
> > On 10/24/06, EKR <[email-masked]> wrote:
> >> "Rohan Mahy" <[email-masked]> writes:
> >> > On 10/23/06, Jonathan Rosenberg <[email-masked]> wrote:
> >> >> * added "anonymous gruu", known as temporary gruu. A 
> temporary GRUU is
> >> >>    assigned when you first register a contact, and an 
> additional one is
> >> >>    created on each refresh. All of the ones accumulated over the
> >> >>    lifetime of the registration remain valid. Each of 
> them obfuscate
> >> >>    the AOR and instance ID. Added a description of a stateless
> >> >>    algorithm for computing these. Lengthy discussion on 
> the privacy
> >> >>    implications of using them.
> >> >
> >> > I just reviewed the extremely lengthy thread on GRUU privacy and 
> >> > have yet to see anything resembling consensus on which 
> privacy or 
> >> > limited-user requirements we are trying to add here.
> >>
> >> I'm not sure I agree with this assertion, but I certainly 
> don't think 
> >> there was consensus on *not* including some privacy mechanisms.
> >
> > Actually there was such a consensus when we took the 
> requirements and 
> > formally handed them to SIP.
> 
> Maybe so, but there's not now, and now is what's important 
> for assessing WG consensus on moving a document forward.
> 
> 
> >> >  Furthermore I
> >> > expect that the mechanism provided could be abused by 
> UAs that want 
> >> > a private per call for example, creating a lot of registration 
> >> > thrash, jeopardizing the avalanche restart prevention 
> work in outbound.
> >>
> >> I don't understand what the security problem you're concerned with 
> >> is. Can you describe the scenario in more detail?
> >
> > Its not a security problem.  It is an operational problem. A user 
> > agent that fetches new gruu for every new call would add a 
> substantial 
> > amount of additional load on a registrar, especially if 
> that registrar 
> > was also doing outbound processing.
> 
> I don't see that. Why?
> 
> -Ekr
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Rohan Mahy" <[email-masked]>
Date: Thu, 26 Oct 2006 11:43:30 -0700

Hi Keith,

To that end, I am reposting here some ideas I sent to the GRUU design
team for an explicit lifetime and explicit privacy mechanism.  Note
that I am using gruu-10 style syntax because I was more familiar with
that syntax when I wrote this up:

-----------

I'd been meaning to post some of my thoughts about a more explicit
method of fetching limited-use, pseudonymous, and/or anonymous GRUUs.
I had been hoping to submit a draft on this topic for several IETFs
now, but did not have the cycles.  (Last time I spent my extra -00
draft energy on the speermint fiasco.)

I heard several different sets of requirements mentioned on the call
yesterday.  I think this concept addresses all the requirements I
think I heard, including my one-GRUU-per-call scenario, and some
assumed requirements to do spam prevention from ekr. I think this
mechanism has some additional nice properties.  It works like this.

First the user registers and gets his/her public GRUU as in gruu-10.

REGISTER sip:example.com
To: <sip:[email-masked]>
From: <sip:[email-masked]>
Contact: <sip:1.2.3.4>;+sip.instance="<urn:uuid:00000-00112233445566>"

SIP/2.0 200 OK
To: <sip:[email-masked]>
From: <sip:[email-masked]>
Contact: <sip:1.2.3.4>;+sip.instance="<urn:uuid:00000-00112233445566>"
 ;expires=3600;gruu="sip:[email-masked];opaque=12345;gruu"

In addition, anytime the user wants a new limited-use or anonymous
GRUU, he/she sends a new register request like this:

REGISTER sip:example.com
To: <sip:[email-masked];opaque=12345;gruu>
From: <sip:[email-masked]>
Contact: <sip:[email-masked];opaque=12345;gruu>
Expires: 86400
Privacy: gruu

SIP/2.0 200 OK
To: <sip:[email-masked];opaque=12345;gruu>
From: <sip:[email-masked]>
Contact: <sip:[email-masked];opaque=12345;gruu>;expires=86400
  ;gruu="sip:[email-masked];gruu"
Contact: <sip:[email-masked];opaque=12345;gruu>;expires=42104
  ;gruu="sip:[email-masked];gruu"
Contact: <sip:[email-masked];opaque=12345;gruu>;expires=432710
  ;gruu="sip:[email-masked];opaque=lkas82;gruu"

The limited-use GRUU can have a much longer lifetime than an ordinary
registration.  Also, since they are tied to a public GRUU instead of
to an ordinary Contact URI, the binding can survive reboots, power
offs of several hours, etc.  A UA can refresh or explicitly destroy
these GRUU if it desires. It can have several active limited-use GRUU
at a time, each of which can have different properties (for example
different priv-values).  [The example above has one new anonymous GRUU
that lasts a day, another day-by-day anonymous GRUU that is half
expired, and a non-anonymous limited use GRUU (for a sales person)
that was valid for a week and still has 5 days left.]

The UA can remember its limited-use GRUU in non-volatile storage or it
can issue a simple REGISTER query to get a list of all active
limited-use GRUUs.  If the UA has been off for an extended period of
time and needs a limited-use GRUU, it needs to issue two
registrations, BUT it does not need 2 RTTs.  It can issue both
REGISTER requests at effectively the same time (in any order).

I hope this makes sense.
thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Fri, 27 Oct 2006 11:50:10 -0700

Hi Eric,

On 10/26/06, Eric Rescorla <[email-masked]> wrote:
> I always have trouble learning from examples, so I hope you'll
> forgive me if I've misunderstood.

Of course.

> It seems to me that there are three key points to this proposal:
>
> 1. The "limited-use" GRUU is tied to the long-term GRUU rather than
>    to an AOR.
yes.  one advantage IMO is that the lifetime of the limited-use GRUU
is unrelated to the stability of the underlying connection.  I can
fetch a limited use GRUU, go into a tunnel, come out with a different
IP address, and reregister my instance without having to refresh any
of my limited-use GRUUs.

> 2. The client explicitly controls limited-use GRUUs rather than
>    having them issued by the server as an automatic side effect
yes.  if I want a 5 minute validity GRUU or a week long validity GRUU
I can get one and refresh (or not) independently.

I can also get a GRUU that is limited use but still tied to my AOR.
Possibly useful for allowing that pesky salesperson to bypass my call
screening for a day or two about something important.

As for load, the UA only generates load on the server when it needs
something new. If the UA doesn't need any private GRUU, the server
doesn't need to generate one.  If the UA wants a unique GRUU per-call,
the registrar does not need to do a full outbound-style registration
(making and saving flow tokens, etc.)

> 3. The client proposes the limited-use GRUU, not the server.
no, the server still forms the actual lmited-use GRUU.

thanks,
-rohan

> Do I have this correctly?
>
> The first seems perfectly reasonable. I'd have to think
> about what advantages/disadvantages it had vis-a-vis current GRUU
> approaches. The second seems fine, but I'm not sure it's really
> that much of an improvement over the current approach. Why does
> it significantly reduce the load on the server that you were
> concerned about. The third point seems to have the significant
> disadvantage that it requires the server to keep state for each
> client-requested limited-use GRUU. I understood that reducing the
> amount of server-side state was an an important consideration
> for many...
>
> -Ekr
>
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Oct 2006 16:24:40 -0400

inline.

> IP address, and reregister my instance without having to refresh any

I'm confused. In the current -11 mechanism, the same thing is true; if 
you go into a tunnel and you get a new IP address when you come out, you 
register with a new IP address and the same instance ID. All existing 
gruu continue to work. There are no extra registrations.

However your mechanism has the major disadvantage of requiring an extra 
REGISTER to allocate a new temporary gruu prior to an anonymous call. 
That extra registration is a big deal for many systems. COnsider the 
craziness IMS goes through when a register happens.

> I can get one and refresh (or not) independently.

WIth whats in -11 the idea is that the lifetime is the length of your 
registration, and that normally you are not wanting to kill the validity 
of the temporary gruu - thats not a privacy issue, its a spam issue. If 
you do want to kill it, you can use the consent framework for example to 
do that. But thats a secondary need.

> (making and saving flow tokens, etc.)

In -11 there is no extra messaging load on the server beyond regular 
registration handling, and it gives the client a near infinite suppy of 
unlinkable addresses, so that a user can use a different one in each 
call without any additional signaling.

> no, the server still forms the actual lmited-use GRUU.

THen I'm confused like ekr. I thought your proposal had the contact of 
the second registration containing the temporary gruu.

-Jonathan R.

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 13:26:18 -0700

> IP address, and reregister my instance without having to refresh any

Right.

> (making and saving flow tokens, etc.)

I'm not an expert on SIP stacks, so maybe I'm missing something
here, but doesn't JDR's new draft have a lightweight way to 
fetch a new anonymous GRUU?

> no, the server still forms the actual lmited-use GRUU.

Can you explain how that works again? I didn't quite get it from
your example.

Thanks,
-Ekr

---

From: "Rohan Mahy" <[email-masked]>
Date: Sun, 29 Oct 2006 07:36:13 -0800

Hi Jonathan,

Sorry, I was a little sloppy in my description. Inline.

> gruu continue to work. There are no extra registrations.

You said below that the lifetime of my private GRUU is the lifetime of
my registration.  I am assuming here that the old registration gets
replaced when I come out of the tunnel and reregister.  Does the old
private GRUU I handed out cease to work?  If so my UA needs to inform
any other UAs that might be using my private GRUU.

With the proposal I described the private GRUU has a completely
independent lifetime.  It is still valid when you come out of the
tunnel.  If a UA gave this private GRUU to another UA, it doesn't need
to replace a previously given GRUU.

Also, the explicit lifetime provides another advantage.  If I have a
device which is registered continuously for weeks at a time, any
private GRUU I received as a side effect of refreshing my subscripion
is still valid. If I start to get SPIM to one of these private GRUU,
the only mechanism I have to squelch the SPIM at my authoritative
proxy is to reregister using a new Call-ID.  If I gave other private
GRUU out that are still useful to me, I need to replace them.

If UAs offer a feature that blocks calls or IMs to a specific GRUU, it
seems like they need to remember all the currently active private
GRUU, which could be a substantial number of URIs.

> craziness IMS goes through when a register happens.

You only need a new register if you don't have a private GRUU cached.
This might mean I need to have my phone off for a whole week to not
have a GRUU.  For emergency calls, I suspect its OK to use your public
GRUU.

Also none of the traditional IMS machinations are necessary for this
kind of REGISTER.  Its effectively a third-party registration.

> do that. But thats a secondary need.

I don't consider limited-lifetimes a secondary need.  Limited lifetime
GRUU deals with reaching a UA instance directly, whereas the consent
framework is most likely doing screening for my public AOR.

> call without any additional signaling.

The point here is that I want to skip the "regular registration
handling" part, which has become increasingly heavy with outbound and
with IMS. I can implement the limited-use GRUU registration
statelessly without requiring a write to the location service.

> the second registration containing the temporary gruu.

In my example, the Contact of the second registration contains the
*public GRUU*.  The ;gruu parameter in each Contact header field value
in the 2xx response to the register contains the *limited-use* GRUU.

thanks,
-rohan

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Oct 2006 07:45:25 -0800

> GRUU out that are still useful to me, I need to replace them.

This feature is more easily implemented with client-issued tokens 
on each GRUU.

> GRUU, which could be a substantial number of URIs.

It's really not that much memory, and you can use a variety of
cryptographic techniques to limit it.

> in the 2xx response to the register contains the *limited-use* GRUU.

OK. Well that partially fixes the problem, but not completely:
the feature you propose where the server is required to give
you back every GRUU its issued requires per-GRUU state on the
server, which is an explit requirements violation.

Let's uplevel a bit:
I'm not fixated on JDR's current mechanism, and I'd be happy to 
consider an alternative that provided superior properties.
That said, I'm not finding documentation by example and e-mail
thread very easy to manage. How about you write a draft on your
approach and its advantages and then JDR, I, and others can
read and comment?

-Ekr

---

From: "Rohan Mahy" <[email-masked]>
Date: Sun, 29 Oct 2006 07:39:22 -0800

> fetch a new anonymous GRUU?

Not that I am aware of.  The registrations in GRUU-11 still require a
write to the location service.

thanks,
-rohan