Subject: [Sip] GRUU - what is there to talk about?

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2007 15:43:47 -0400

Folks may have noticed that GRUU has time on the agenda. There has been 
an open issue that came up, but it was buried in an older thread that 
folks may not have paid attention to.

To refresh everyones memory, a couple of revisions ago, we introduced 
the notion of a temporary GRUU to address concerns that GRUU would 
worsen privacy considerably compared to RFC 3261. The idea is that, when 
a client does a REGISTER (whether initial or refresh), the server 
constructs a new temporary GRUU for the UA. The userpart of the GRUU 
doesn't reveal the identity of the UA, and its temporary because these 
URI become invalid when the clients registration lapses.

The problem that was raised on the list by Paul K. some time back, is 
that you might run into problems when the server forcefully terminates 
the registration. The client will re-register, but how does it 
synchronize its set of temporary GRUU with those the registrar has? The 
solution was to use reg-event (necessary anyway if the server is 
forcefully de-registering users). So, the client would use reg-event, 
and if it sees the server expire its registration in the reg-event 
notify, it discards its temp-gruu.

However, getting into the details of this, it still doesn't quite work. 
If a client re-REGISTERs on the cusp of the expiration, it won't know 
whether its registration came before or after the expiration. The way to 
solve this is that the reg-event notifications contain, within them, the 
  cseq of the registration which was the start of this sequence of valid 
temp-gruu. This way, the client knows that all temp-gruu it learned in 
REGISTER responses with a cseq equal or higher to that one, are valid. 
This also allows a client to use reg-event at any time to verify 
synchronization. Of course, since CSeq are scoped within a call-id, we 
neccesarily need to invalidate temp-gruu when the call-id changes.

This leads to an interesting side-effect - now, a client can forcefully 
terminate all of its current temp-gruu, without unregistering, by 
sending a refresh which changes the call-id. This doesn't provide 
fine-grained expiration control over particular temp-gruu, but it allows 
you to erase them all.

AFAICT, this works just fine. However, its an open issue in that this is 
yet-another-new-temp-gruu thing, an area which we have been struggling 
to stabilize to complete this draft. So I wanted to make sure the group 
was aware of this change, OK with it, and had time to ponder any 
possible implications.

Thanks,
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

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Sat, 17 Mar 2007 09:57:27 +0000

Jonathan Rosenberg wrote:
> synchronize its set of temporary GRUU with those the registrar has? 
> The solution was to use reg-event (necessary anyway if the server is 

I can see what you're getting at here, but (unless I missed something) 
the intention is far less than clear in the current draft.

As far as I can tell, there are only two sections of text that address this:

   In cases where registrars forcefully
   shorten registration intervals, the registration event package, RFC
   3860 [23] is used by user agents to learn of these changes.  A user
   agent implementing both RFC 3680 and GRUU MUST also implement the
   extensions to RFC 3680 for conveying information on GRUU [24], as
   these are necessary to keep the set of temporary GRUU synchronized
   between the UA and the registrar.

...and...

   RFC 3680 [23] defines an event package that allows a client to learn
   about registration events at the registrar.  This package allows
   registrars to alter registrations forcefully (for example, shortening
   them to force a re-registration).  If a registrar is supporting RFC
   3680 and GRUU, it MUST also support [24].

With the context provided by your email on the topic, it's pretty easy 
to figure out what these passages are intended to mean. However, I fear 
that the chance that an average developer has much hope of doing the 
right thing with this information is very slim unless they happen to 
come digging through this mailing list.

In other words, I believe that we need more clearly defined procedures 
for client handling of NOTIFY messages for regevent when they contain 
revised GRUU information. I imagine this would primarily consist of a 
more formal version of your email on the topic.

---

And, since I have an email open on the topic, two nits:

Section 5.4: "Once a temporary GRUU is constructed, it MUST be 
considered valid for the duration that the AOR itself is valid."

I believe that should say "Once a _PUBLIC_ GRUU is constructed..."

Section 4.4: "...the SUBSCRIBE [5] request, its 2xx response or with a 
To tag..."

Either I don't understand what is meant here, or there is a spurious 
"or" in that phrase.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Mar 2007 09:04:57 -0400

inline.

> come digging through this mailing list.

No doubt. The idea was that all of the logic for this would be in the 
reg-event spec. The problem only manifests if you are having the 
registrar shorten registrations, in which case you are using reg-event 
and the text there would explain more.

That said, it can't hurt to add a few sentences here motivating the problem.

> I believe that should say "Once a _PUBLIC_ GRUU is constructed..."

Yes, others made this comment too. Fixed.

> Either I don't understand what is meant here, or there is a spurious 

extra or. Removed.

-Jonathan R.