Subject: [Sip] draft-ietf-sip-sips Open Issues: GRUU

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Feb 2007 18:49:53 -0600

Another open issue in Appendix B of draft-ietf-sip-sips is related to
GRUU.

It says:

   For GRUU, how should the UAC react if the returned GRUU is SIP but
   the To was SIPS?  How should the UAC react if the returned GRUU is
   SIPS but the To was SIP?

In other words, what if the registrar returns a GRUU with the wrong
scheme
in the response to REGISTER.

I can think of the following:

1 - UAC uses the GRUU anyways, BUT replace the scheme with the proper 
    scheme in all usages of GRUU.

2 - UAC behaves as if it did not receive a GRUU at all.

I'm tempted to believe that option 1 is better.

Any opinions? Other ideas?

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 27 Feb 2007 18:55:45 -0600

> Any opinions? Other ideas?

3rd alternative: UAC uses the GRUU as it was returned, but warns the  
user.

Use case: You need a GRUU, but the server just can't knit you a sips:  
GRUU.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Feb 2007 19:06:32 -0600

> 3rd alternative: UAC uses the GRUU as it was returned, but 
> warns the user.

And the only people who will understand the error message will
be IETF SIP WG participants (and probably not even all of us).

Unlike a REFER scenario, this seems way to arcane.

Assuming the warning was more of the "can't do security" variety,
(instead of GRUU specifically), it would then need to be accompanied
by a wholesale downgrade to sip. So in my mind, the UAC would have
to re-REGISTER (if acceptable). Is that what you mean?

I find this kind of scary: wouln't the REGISTER then just reject
the REGISTER altogether with 416 "Unsuported scheme" which would
then trigger the client to re-REGISTER using sip?

> Use case: You need a GRUU, but the server just can't knit you 
> a sips:  GRUU.

>From a routing perspective, a sip GRUU and a sips GRUU point to the 
same resource.

So what do you really mean by server can't knit a GRUU? Keep in mind
this
is a case where server accepts the SIPS in the To, From and Contact, but
nevertheless chooses a sip GRUU. I'm scratching my head trying to figure
out why this is a valid scenario. And if it is, why rejecting the
REGISTER
wouldn't be better.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Feb 2007 10:02:36 -0600

This kind of feels like the "what do we say to do when something  
wildly violates the spec" conversation.
(My current read of GRUU says that the registrar went off the rails  
to do this - am I wrong?).

In the past, we've shied away from specifying recovery behavior for  
all these cases - there are just too many
of them. There have been times when it's been important to specify  
what happens because of (usually) security
issues. Maybe this is one of those. If it is, the clarification needs  
to land in the GRUU spec I think.

My own inclination is to say 2), and say it in the GRUU document.

RjS

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 28 Feb 2007 10:04:42 -0600

Yes, this is exactly what it is: it's the case where the registrar went off
the rails.

I'm perfectly happy with your suggestion that we do (2).

I don't care if we say it in this document or in GRUU.

Jonathan? Any preferences?

----
François AUDET, Nortel Networks
mailto:[email-masked]

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Wed 28-Feb-07 8:02 AM
To: Audet, Francois (SC100:3055)
Cc: SIP
Subject: Re: [Sip] draft-ietf-sip-sips Open Issues: GRUU

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 14:00:14 -0500

I'd prefer option 1. The reason is, if the registrar does properly 
handle the sips version of your gruu, but just didn't tell you about it, 
then in option 1, things still work.

Specifying this doesn't belong in GRUU since we had decided previously 
to eliminate almost all discussion on SIPS from GRUU. So it would be way 
out of place to say it there.

Indeed, since we are saying that sip and sips URI are basically 
equivalent, I would argue that the scheme in the To header field of the 
REGISTER is really irrelevant entirely. The key is really the R-URI and 
Contact in the register. If they are both sips, then the result is a 
"secure" link from the client to the registrar. Once that is in place, a 
call to the sips version of the AOR can be routed over this link, using 
the sips COntact and sips Path that would have been created by the 
registration. Similarly a call to a SIP URI could use that link too.

Another related point, with current registrar behavior of replacing the 
R-URI with the registered contact, if I send a REGISTER request with a 
sips Contact and sips URI, and then someone sends me a call to the sip 
version of my AOR, the r-uri will be translated to the sips contact I 
had registered. So how does a sips-only client reject this? I'm 
referring to paragraph 4 in section 5. Not a GRUU question per se, but 
related.

I'll note that this issue is solved with UA loose route.

-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: "Francois Audet" <[email-masked]>
Date: Wed, 28 Feb 2007 15:28:25 -0600

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 11:00
> Cc: Robert Sparks; SIP
> I'd prefer option 1. The reason is, if the registrar does 
> properly handle the sips version of your gruu, but just 
> didn't tell you about it, then in option 1, things still work.

Yes, this was my preference as well, for exactly the same reason.

I'm ok with both 1 and 2, but I prefer 1.

I'll wait to see if anybody elses chimes in. If not, and I don't get
strong pushback from Robert, I'll use the option 1 approach.

> Specifying this doesn't belong in GRUU since we had decided 
> previously to eliminate almost all discussion on SIPS from 
> GRUU. So it would be way out of place to say it there.

Ok.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Feb 2007 15:33:59 -0600

On Feb 28, 2007, at 1:00 PM, Jonathan Rosenberg wrote:

> handle the sips version of your gruu, but just didn't tell you  
> about it, then in option 1, things still work.
I'm still very nervous.
What about something in the middle twidding bits (replacing sips:  
with sip: in the GRUU in the contact in the register response?)
I see the sunny case working that you're describing, but are you sure  
its not enabling something you don't _want_ to work?

> previously to eliminate almost all discussion on SIPS from GRUU. So  
> it would be way out of place to say it there.
If the answer is 2) then I disagree. It is more or less the same as  
saying what to do if your gruu parameter comes back with an http: URI  
in it.

> equivalent, I would argue that the scheme in the To header field of  
> the REGISTER is really irrelevant entirely.
Agreed.
> The key is really the R-URI and Contact in the register.
I was only looking at the scheme in the contact URI when I was  
thinking about this.
> If they are both sips, then the result is a "secure" link from the  
> client to the registrar. Once that is in place, a call to the sips  
> version of the AOR can be routed over this link, using the sips  
> COntact and sips Path that would have been created by the  
> Another related point, with current registrar
you mean a retargeting proxy?
> behavior of replacing the R-URI with the registered contact, if I  
> send a REGISTER request with a sips Contact and sips URI, and then  
> someone sends me a call to the sip version of my AOR, the r-uri  
> will be translated to the sips contact I had registered.
? I'm lost. Probably by the same thing that made me ask the question  
above.
Maybe I'm not following Francois draft closely enough - did we decide  
to allow upgrades when retargeting?

> So how does a sips-only client reject this? I'm referring to  
> paragraph 4 in section 5. Not a GRUU question per se, but related.
>
>> (My current read of GRUU says that the registrar went off the  
>> rails to do this - am I wrong?).
>> In the past, we've shied away from specifying recovery behavior  
>> for all these cases - there are just too many
>> issues. Maybe this is one of those. If it is, the clarification  
>> needs to land in the GRUU spec I think.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Feb 2007 15:48:25 -0600

> strong pushback from Robert, I'll use the option 1 approach.

I commented on Jonathan's response, but it's not strong pushback.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 28 Feb 2007 15:59:32 -0600

I'm changing the Subject field because Jonathan is
pointing out another important issue.

> Another related point, with current registrar behavior of 
> replacing the R-URI with the registered contact, if I send a 
> REGISTER request with a sips Contact and sips URI, and then 
> someone sends me a call to the sip version of my AOR, the 
> r-uri will be translated to the sips contact I had 
> registered. So how does a sips-only client reject this? I'm 
> referring to paragraph 4 in section 5. Not a GRUU question 
> per se, but related.

Actually, I the problem you are refering to affects not
only REGISTER, but any requests that has a Contact (like
an INVITE, if you expect mid-dialog requests).

That problem is something that I noticed was a big problem
in earlier versions of this draft (i.e., draft-ietf-sip-sips-00,
and the individual drafts draft-audet-sip-sips-guidelines).
Basically, it was broken

I had done a change in this version of the draft (i.e.,
draft-ietf-sip-sips-01) to address this. Look at the
second paragraph of section 4. (The call flows have been
adjusted for this too).

Basically, it says that the proxy must keep the same 
scheme (sip or sips) that was in the incoming request
before delivering it (i.e., sip -> sip, and sips -> sips).
If we don't do that, we'll have the problem you are
describing, but we'll also have a bigger problem with
mid-dialog requests.

To me this is consistent with the idea that schemes are 
equivalent from a routing perspective.

So yes, the proxy replaces the contact with the registered
contact, but it keeps the originial scheme of the request
that it is forwarding.

> I'll note that this issue is solved with UA loose route.

Yes it would. But I think proxies should nevertheless
keep the same scheme (sip or sips) when forwarding a
request to the client. Otherwise, it makes SIPS 
dependent on loose routes. I do not think that it would be
warranted to make that a dependency.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 18:00:11 -0500

Robert Sparks wrote:

>> handle the sips version of your gruu, but just didn't tell you  about 
>> it, then in option 1, things still work.
> 
> I'm still very nervous.
> What about something in the middle twidding bits (replacing sips:  with 
> sip: in the GRUU in the contact in the register response?)

For what purpose? WIth option 2, this would cause a loss of function. 
WIth option 1, it has no effect.

> its not enabling something you don't _want_ to work?

Not that I can think of. Since the sip and sips URI are equivalent 
anyway, what harm can this do? Of course an attacker capable of 
modifying messages can do so much worse than tweaking a sip scheme to 
sips......

> saying what to do if your gruu parameter comes back with an http: URI  

Which one can always specify in another draft. We agreed to keep SIPS 
out of GRUU entirely. THe fact that we are debating an open issue around 
how to use SIPS with GRUU is exactly why.

> I was only looking at the scheme in the contact URI when I was  thinking 
> about this.
> 
>> someone sends me a call to the sip version of my AOR, the r-uri  will 
>> be translated to the sips contact I had registered.
> 

Francois has another thread on this.

-Jonathan R.