Subject: Re: [Sip] GRUU and Grid alternative

From: Dean Willis <[email-masked]>
Date: Tue, 03 Oct 2006 23:17:08 -0500

Jonathan Rosenberg wrote:

> The basic idea would be to remove the grid mechanism entirely from the 
> gruu draft. Instead, a separate specification would be developed which 
> would allow for loose routing to apply to user agents. So, consider a UA 
> which registers. It would include a contact and a Supported header field 
> with the value "ua-route". The registrar, assuming it understands this, 
> notes that the UA supports UA loose routing and stores the contact. When 
> an incoming call arrives for the AOR, rather than rewriting the R-URI 
> with the registered contact, it pushes the registered contact into a 
> Route header and leaves the R-URI alone (assuming the registered UA 
> supports this mechanism).

I'd like to go on record as saying that this apparently resolves one of 
the Great Fundamental Evils of SIP that I've so often sermonized and 
thereby either makes me happy and fulfilled or leaves me looking for 
something else to whine about. In either case, it is a very good fix, 
and long overdue.

--
Dean

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Wed, 4 Oct 2006 13:18:52 -0500

I'd like to point one thing out from the annals of the way-back
machine...

At IETF-59 in Seoul, I made a presentation, which I recall being well
received by at least a few folks (I believe Cullen was one of them) in
which a separate, but related problem space to GRUU was being discussed:
the GUID.

The draft has expired long ago
(http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-stucker-si
p-guid-00.txt) but the introduction captures the problem space fairly
succintly:

---
      Within SIP, there arise situations where it is necessary to ensure

      that an action is applied to a particular user agent (UA)
instance, 
      but the existing mechanisms within SIP are not always reliable.
For 
      example, although registrations identify a routable address and
port 
      of a particular UA, in an environment that uses dynamically
assigned 
      IP addresses (NATs, VPNs, short-lease DHCP networks) there is no 
      ready way of always tying registrations together across time for a

      particular UA instance. In these environments, the usual IP/port 
      combination that defines a particular routing location of a UA is 
      unreliable over time as an identifier of that UA. 

      As a result, an identifier that UAs can use as a "finger-printing"

      mechanism to identify themselves is useful. Whereas the Globally 
      Routable UA URIs (GRUU) draft [4] seeks to address a
server-generated 
      identifier for the UA, this draft seeks to define a
client-generated 
      approach to a similar problem. 

      The mechanism defined in this document allows a particular UA 
      instance to construct a globally unique identifier which can be
used 
      by SIP services to process requests that require, or are enhanced
by, 
      the ability to identify a particular UA instance in the network
over 
      a long period of time. 
---

This notion was folded into the GRUU draft as a property of the grid
parameter (ie. the grid could be used as a GUID).

If we're to remove the grid from gruu, I think we still want to maintain
this property of the grid: it's still very useful.

Regards,
Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, October 03, 2006 11:17 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] GRUU and Grid alternative
> 
> > would allow for loose routing to apply to user agents. So, 
> consider a 
> > UA which registers. It would include a contact and a 
> Supported header 
> > field with the value "ua-route". The registrar, assuming it 
> > understands this, notes that the UA supports UA loose routing and 
> > stores the contact. When an incoming call arrives for the 
> AOR, rather 
> > than rewriting the R-URI with the registered contact, it pushes the 
> > registered contact into a Route header and leaves the R-URI alone 
> > (assuming the registered UA supports this mechanism).
> 
> I'd like to go on record as saying that this apparently 
> resolves one of the Great Fundamental Evils of SIP that I've 
> so often sermonized and thereby either makes me happy and 
> fulfilled or leaves me looking for something else to whine 
> about. In either case, it is a very good fix, and long overdue.
> 
> --
> Dean
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 4 Oct 2006 13:25:46 -0500

I believe what you are describing here is essentially extending the
routing mechanism used within the IMS core network to route messages
between various servers (x-CSCFs, BGCFs, App Servers, etc). 

Although this may help with a number of issues, and on the face of it is
a relatively simple idea (use a separate stack data structure for
routing instead of a static URI) I don't think it solves all the
problems you may think it does.

For instance, existing P-headers also have a trust-domain and network
assertion factor associated with them.

Regards,
Brian

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, September 27, 2006 12:50 AM
> To: IETF SIP List
> Subject: [Sip] GRUU and Grid alternative
> 
> During our call on GRUU last week, there was a discussion on 
> this issue that ekr raised, where he would like to see the 
> grid usable outside of just gruu, i.e., with any AOR.
> 
> During the call, I made a suggestion for an alternative 
> solution, and there was agreement amongst those on the call 
> for the proposed approach.
> 
> The basic idea would be to remove the grid mechanism entirely 
> from the gruu draft. Instead, a separate specification would 
> be developed which would allow for loose routing to apply to 
> user agents. So, consider a UA which registers. It would 
> include a contact and a Supported header field with the value 
> "ua-route". The registrar, assuming it understands this, 
> notes that the UA supports UA loose routing and stores the 
> contact. When an incoming call arrives for the AOR, rather 
> than rewriting the R-URI with the registered contact, it 
> pushes the registered contact into a Route header and leaves 
> the R-URI alone (assuming the registered UA supports this mechanism).
> 
> How does this solve the grid problem? Lets say my AOR is 
> sip:[email-masked]. I, as a UA, can mint a URI with some 
> arbitrary parameter, say sip:[email-masked];foo=baz, and 
> hand it out to some correspondent. When a correspondent sends 
> a request to that URI, it arrives at my home proxy. From 
> there, since the R-URI is NOT rewritten, the entire URI, 
> parameters and all, is passed to the UA. Thus, the UA knows 
> the URI that was de-referenced. We wouldn't necessarily have 
> to standardize a specific URI parameter, like grid, to carry 
> the opaque data.
> 
> This trick solves a whole bunch of other problems too. It 
> would eliminate the need for the IMS P-Called-Party-ID header 
> field, and it would help clarify when a request is retargeted 
> (change in R-URI) vs. 
> when its just being delivered to the recipient (no change in R-URI).
> 
> Comments?
> 
> -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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Oct 2006 15:22:55 -0400

I'm lost on what this has to do with grid... isnt the instance ID the 
client generated identifier?

-Jonathan R.

Brian Stucker wrote:

>>>The basic idea would be to remove the grid mechanism 
>>
>>entirely from the 
>>
>>>gruu draft. Instead, a separate specification would be 
>>
>>developed which 
>>

-- 
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Oct 2006 15:24:11 -0400

I don't follow. The only P-header issue this solves is 
P-Called-Party-ID. That header was added to deal exactly with this issue 
of the r-uri being rewritten, so the UAS doesn't know which public 
identity was targeted by the request. By not rewriting the request URI 
that problem is eliminated.

What trust-domain issues are you referring to?

-Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 4 Oct 2006 15:42:10 -0500

Looking at RFC-3455, and how the P-Called-Party-ID header is defined,
there are some implications that weren't represented in the approach
below that I think we should consider.

For instance, Section 6.2 of RFC-3455 brings up a good point about the
security and privacy issues around using the P-Called-Party-ID header.
If the proposed mechanism is used to obviate the need for this header,
or otherwise used to mimic the header's purpose we would have to address
those concerns.

Further, Section 4.2.2.1 states that the UAC MUST NOT insert a
P-Called-Party-ID header field in any SIP request. This is because this
it would potentially violate the transitive trust statement of
applicability given in Section 1 of RFC-3455. I believe, by relying on
the value of the R-URI specified by the UAC if this mechanism replaces
the P-Called-Party-ID header, we'd be violating the spirit of Section
4.2.2.1 of RFC-3455.

Regards,
Brian

> Sent: Wednesday, October 04, 2006 2:24 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: IETF SIP List
> P-Called-Party-ID. That header was added to deal exactly with 
> this issue of the r-uri being rewritten, so the UAS doesn't 
> know which public identity was targeted by the request. By 
> not rewriting the request URI that problem is eliminated.
> 
> > Although this may help with a number of issues, and on the 
> face of it 
> > is a relatively simple idea (use a separate stack data 
> structure for 
> >>During our call on GRUU last week, there was a discussion on this 
> >>issue that ekr raised, where he would like to see the grid usable 
> >>outside of just gruu, i.e., with any AOR.
> >>
> solution, and 
> >>there was agreement amongst those on the call for the proposed 
> >>approach.
> >>
> arbitrary 
> >>parameter, say sip:[email-masked];foo=baz, and hand it 
> out to some 
> >>correspondent. When a correspondent sends a request to that URI, it 
> >>arrives at my home proxy. From there, since the R-URI is NOT 
> >>rewritten, the entire URI, parameters and all, is passed to the UA. 
> >>Thus, the UA knows the URI that was de-referenced. We wouldn't 
> >>necessarily have to standardize a specific URI parameter, 
> like grid, 
> >>to carry the opaque data.
> >>
> >>This trick solves a whole bunch of other problems too. It would 
> >>eliminate the need for the IMS P-Called-Party-ID header 
> field, and it 
> >>would help clarify when a request is retargeted (change in 
> R-URI) vs.
> >>[email-masked] for questions on current sip Use 
> >>[email-masked] for new developments on the application of sip
> >>
> > 
> > 
> 
> --

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Oct 2006 12:15:57 -0400

Unfortunately, I don't think this eliminates the need for 
P-Called-Party-ID in IMS.

In IMS, when the AOR in the R-URI is translated to a contact address in 
the R-URI, a P-Called-Party-ID header is added containing that AOR. 
Later, a downstream proxy (the terminating P-CSCF) remembers this value 
when forwarding the request to the UAS. Then when the response comes 
back from the UAS, that proxy adds a P-Asserted-Identity header using 
the value from the P-Called-Party-ID header of the request. In this way, 
the identity of the called party is asserted. Until now, plans to carry 
gruu into IMS have proposed that when a gruu is translated, the 
P-Called-Party-ID header should be set to the AOR, not the gruu.

While we have lots of identity work in process that addresses similar 
issues in different ways. But meanwhile that is what IMS does.

It depends on P-Called-Party-ID containing something suitable for use as 
an identity, suitable for authorization decisions, etc.  To make this 
work with gruu, until now plans to carry gruu into IMS have proposed 
that when a gruu is translated, the P-Called-Party-ID header should be 
set to the AOR, not the gruu.

If loose routing of the contact is adopted, and the P-Called-Party-ID 
usage is eliminated, then the identity of the called party would have to 
be inferred from the R-URI. For instance in this case if the callee was 
identified by an assigned anonymous gruu, then the identity coming back 
would have that, which wouldn't be very useful.

At the moment, I expect that IMS may well continue to need 
P-Called-Party-ID even after this change. That of course is subject to 
further consideration, but lets not count our benefits until they have 
been confirmed.

	Paul

Jonathan Rosenberg wrote:
>>> From: Jonathan Rosenberg [mailto:[email-masked]] Sent: Wednesday, 
>>> September 27, 2006 12:50 AM
>>> To: IETF SIP List
>>> During the call, I made a suggestion for an alternative solution, and 
>>> there was agreement amongst those on the call for the proposed approach.
>>>
>>> The basic idea would be to remove the grid mechanism entirely from 
>>> the gruu draft. Instead, a separate specification would be developed 
>>> which would allow for loose routing to apply to user agents. So, 
>>> consider a UA which registers. It would include a contact and a 
>>> Supported header field with the value "ua-route". The registrar, 
>>> assuming it understands this, notes that the UA supports UA loose 
>>> routing and stores the contact. When an incoming call arrives for the 
>>> AOR, rather than rewriting the R-URI with the registered contact, it 
>>> pushes the registered contact into a Route header and leaves the 
>>> R-URI alone (assuming the registered UA supports this mechanism).
>>>
>>> sip:[email-masked]. I, as a UA, can mint a URI with some arbitrary 
>>> parameter, say sip:[email-masked];foo=baz, and hand it out to some 
>>> necessarily have to standardize a specific URI parameter, like grid, 
>>> eliminate the need for the IMS P-Called-Party-ID header field, and it 
>>> would help clarify when a request is retargeted (change in R-URI) vs.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 5 Oct 2006 13:26:49 -0500

I agree with your assessment Paul. There are definitely cases in 23.228
that use the P-Called-Party-ID header to later create a P-Asserted-ID
header.

The reason I bring it up was two-fold: as you say, it we may be counting
chickens too early, and because if we are counting on similar properties
of the R-URI behavior in the proposed mechanism (which I think is an
interesting proposal)  for non-3GPP related problems, those chickens may
be in jeopardy as well.

Regards,
Brian

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, October 05, 2006 11:16 AM
> To: Jonathan Rosenberg
> Cc: Stucker, Brian (RICH1:AR00); IETF SIP List
> In IMS, when the AOR in the R-URI is translated to a contact 
> address in the R-URI, a P-Called-Party-ID header is added 
> containing that AOR. 
> Later, a downstream proxy (the terminating P-CSCF) remembers 
> this value when forwarding the request to the UAS. Then when 
> the response comes back from the UAS, that proxy adds a 
> P-Asserted-Identity header using the value from the 
> P-Called-Party-ID header of the request. In this way, the 
> identity of the called party is asserted. Until now, plans to 
> carry gruu into IMS have proposed that when a gruu is 
> translated, the P-Called-Party-ID header should be set to the 
> AOR, not the gruu.
> 
> While we have lots of identity work in process that addresses 
> similar issues in different ways. But meanwhile that is what IMS does.
> 
> It depends on P-Called-Party-ID containing something suitable 
> for use as an identity, suitable for authorization decisions, 
> etc.  To make this work with gruu, until now plans to carry 
> gruu into IMS have proposed that when a gruu is translated, 
> the P-Called-Party-ID header should be set to the AOR, not the gruu.
> 
> If loose routing of the contact is adopted, and the 
> P-Called-Party-ID usage is eliminated, then the identity of 
> the called party would have to be inferred from the R-URI. 
> For instance in this case if the callee was identified by an 
> assigned anonymous gruu, then the identity coming back would 
> have that, which wouldn't be very useful.
> 
> P-Called-Party-ID even after this change. That of course is 
> subject to further consideration, but lets not count our 
> benefits until they have been confirmed.
> 
> 	Paul
> 
> > P-Called-Party-ID. That header was added to deal exactly with this 
> > issue of the r-uri being rewritten, so the UAS doesn't know which 
> > public identity was targeted by the request. By not rewriting the 
> > request URI that problem is eliminated.
> > 
> >>> During the call, I made a suggestion for an alternative solution, 
> >>> and there was agreement amongst those on the call for the 
> proposed approach.
> >>>
> entirely from 
> >>> routing and stores the contact. When an incoming call arrives for 
> >>> the AOR, rather than rewriting the R-URI with the registered 
> >>> contact, it pushes the registered contact into a Route header and 
> >>> leaves the R-URI alone (assuming the registered UA 
> >>> arbitrary parameter, say sip:[email-masked];foo=baz, 
> and hand it 
> >>> out to some correspondent. When a correspondent sends a 
> request to 
> >>> that URI, it arrives at my home proxy. From there, since 
> the R-URI 
> >>> is NOT rewritten, the entire URI, parameters and all, is 
> passed to the UA.
> field, and 
> >>> it would help clarify when a request is retargeted 
> (change in R-URI) vs.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Oct 2006 14:43:02 -0400

> or otherwise used to mimic the header's purpose we would have to address

OK, lets take a look. Here is the contents of that section:

6.2 P-Called-Party-ID

    Due to the nature of the P-Called-Party-ID header, this header does
    not introduce any significant security concern.  It is possible for
    an attacker to modify the contents of the header.  However, this
    modification will not cause any harm to the session establishment.

    An eavesdropper may collect the list of identities a user is
    registered.  This may have privacy implications.  To mitigate this
    problem, this extension SHOULD only be used in a secured environment,
    where encryption of SIP messages is provided either end-to-end or
    hop-by-hop.

The second paragraph is the only one that raises an issue. The issue 
actually has nothing to do with p-called-party-id. If you are worried 
about knowing what identities a user was registered under, you need only 
snoop the REGISTER message. The security mitigation for this is to 
protect the SIP signaling path using sips or TLS, which would protect 
the REGISTER, and of course INVITE towards the UAS. That would hide the 
p-called-party-id and request-URI from eavesdroppers.

So I don't see any issue here.

> the P-Called-Party-ID header, we'd be violating the spirit of Section

I disagree. In fact, the requirement of not inserting is an artifact of 
the fact that it IS a separate header. If you use the R-URI the security 
issue goes away.

The security concern is that if the UE has special treatment for an 
incoming call based on the called party ID (for example, special 
ringtones), the caller can insert this value in P-Called-Party-ID while 
using a different value in the R-URI. If the P-Called-Party-ID is passed 
to the UE, it can result in the wrong behavior.

Of course, you wouldn't have this problem in the first place if the 
called party ID were present only in the request-URI, per my proposal. 
The security problem happens because the called party ID is present in 
TWO places (the R-URI up to the terminating proxy, and the called-party 
ID after it), and thus they can be inconsistent. If there is only one 
place, there is no chance of consistency problems.

Consequently, I see the UA loose routing mechanism only improving upon 
the security issue with P-Called-Party-ID.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Oct 2006 14:49:23 -0400

This is a good point; thanks Paul.

I think there is a deeper question here about whether the calling party 
has a right to know the called party identity beyond the information 
revealed by the GRUU. If the GRUU is anonymous, the caller only has the 
anonymous URI, and presumably this is because the called party wanted to 
remain anonymous. Should then the P-CSCF provide the actual called party 
identity to the caller after the call completes? I would think this is a 
bad thing and a violation of privacy, no?

-Jonathan R.

Paul Kyzivat wrote:
>>>> and there was agreement amongst those on the call for the proposed 
>>>> approach.
>>>>
>>>> leaves the R-URI alone (assuming the registered UA supports this 
>>>> mechanism).
>>>>
>>>> arbitrary parameter, say sip:[email-masked];foo=baz, and hand it 
>>>> out to some correspondent. When a correspondent sends a request to 
>>>> that URI, it arrives at my home proxy. From there, since the R-URI 
>>>> is NOT rewritten, the entire URI, parameters and all, is passed to 
>>>> the UA. Thus, the UA knows the URI that was de-referenced. We 
>>>> wouldn't necessarily have to standardize a specific URI parameter, 
>>>> like grid, to carry the opaque data.
>>>>
>>>> eliminate the need for the IMS P-Called-Party-ID header field, and 
>>>> it would help clarify when a request is retargeted (change in R-URI) 
>>>> vs. when its just being delivered to the recipient (no change in 
>>>> R-URI).
>>>>
>>>> Comments?
>>>>
>>>> -Jonathan R.
>>>>
>>>>
>>>> --

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 5 Oct 2006 14:16:01 -0500

I think you may want to look at what the header gets used for in the
24.229 procedures. It gets used to populate values that definitely do
have a trust domain context associated with them. I didn't want to get
into the guts of discussing a 3GPP document on an IETF list in the
earlier email.

Re Section 4.2.2.1: 
I don't think it has anything to do with the fact that it's two headers
or not, you want to know that the value that's there is correct. If I
understand the proposal correctly, you're also using two headers: route
and R-URI. So if you feel that having two headers really is the issue
here, then what's the difference?

Re Section 6.2:
In a general sense, can't I make the R-URI say anything I want by doing
the following:

INVITE sip:anything-i-want@domain SIP/2.0
Route: <sip:the-real-place-I-want-to-route-to@domain;lr>

When the next hop gets this, it's going to ignore the R-URI, route on
the Route header, and not change the R-URI.

It's just a matter of knowing how many hops you may need to cover with
loose-route route headers to get past the point you want to get past
with the bogus R-URI header. It's not necessarily going to interfere
with your session setup, as per the first paragraph of Section 6.2, but
it doesn't mean that the value is correct either.

Regards,
Brian 

> Sent: Thursday, October 05, 2006 1:43 PM
> > or otherwise used to mimic the header's purpose we would have to 
> > address those concerns.
> 
> The second paragraph is the only one that raises an issue. 
> The issue actually has nothing to do with p-called-party-id. 
> If you are worried about knowing what identities a user was 
> registered under, you need only snoop the REGISTER message. 
> The security mitigation for this is to protect the SIP 
> signaling path using sips or TLS, which would protect the 
> REGISTER, and of course INVITE towards the UAS. That would 
> hide the p-called-party-id and request-URI from eavesdroppers.
> 
> > P-Called-Party-ID header field in any SIP request. This is because 
> > this it would potentially violate the transitive trust statement of 
> > applicability given in Section 1 of RFC-3455.  I believe, 
> by relying 
> > on the value of the R-URI specified by the UAC if this mechanism 
> > replaces the P-Called-Party-ID header, we'd be violating 
> the spirit of 
> > Section
> > 4.2.2.1 of RFC-3455.
> 
> I disagree. In fact, the requirement of not inserting is an 
> artifact of the fact that it IS a separate header. If you use 
> the R-URI the security issue goes away.
> 
> The security concern is that if the UE has special treatment 
> for an incoming call based on the called party ID (for 
> example, special ringtones), the caller can insert this value 
> in P-Called-Party-ID while using a different value in the 
> R-URI. If the P-Called-Party-ID is passed to the UE, it can 
> result in the wrong behavior.
> 
> Of course, you wouldn't have this problem in the first place 
> if the called party ID were present only in the request-URI, 
> per my proposal. 
> The security problem happens because the called party ID is 
> present in TWO places (the R-URI up to the terminating proxy, 
> and the called-party ID after it), and thus they can be 
> inconsistent. If there is only one place, there is no chance 
> of consistency problems.
> 
> Consequently, I see the UA loose routing mechanism only 
> improving upon the security issue with P-Called-Party-ID.
> 
> -Jonathan R.
> 
> 
> --

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Oct 2006 17:38:52 -0400

> bad thing and a violation of privacy, no?

Well, the P-Asserted-Identity in the response is largely there for use 
by servers in the trust domain. It can be removed before it exits the 
trust domain, so that it isn't made available to the caller, if desired. 
But I don't think that is currently done, and in fact may negate some of 
the intent of the feature. Typically it would only be removed in the 
forward direction based on the Privacy:id header. I don't think id 
privacy in the reverse direction is supported, though perhaps it could 
be. That might be the proper answer in this case.

It is a bit of a fuzzy area wrt the details of IMS, and in large part is 
probably not an issue for ietf. Presumably IMS can continue to use 
P-Called-Party-ID if they want to. And *maybe* they will find that it is 
no longer needed. We just don't know yet.

	Paul

>> In IMS, when the AOR in the R-URI is translated to a contact address 
>> in the R-URI, a P-Called-Party-ID header is added containing that AOR. 
>> Later, a downstream proxy (the terminating P-CSCF) remembers this 
>> value when forwarding the request to the UAS. Then when the response 
>> comes back from the UAS, that proxy adds a P-Asserted-Identity header 
>> using the value from the P-Called-Party-ID header of the request. In 
>> this way, the identity of the called party is asserted. Until now, 
>> plans to carry gruu into IMS have proposed that when a gruu is 
>> translated, the P-Called-Party-ID header should be set to the AOR, not 
>> the gruu.
>>
>> It depends on P-Called-Party-ID containing something suitable for use 
>> as an identity, suitable for authorization decisions, etc.  To make 
>> this work with gruu, until now plans to carry gruu into IMS have 
>> proposed that when a gruu is translated, the P-Called-Party-ID header 
>> should be set to the AOR, not the gruu.
>>
>> usage is eliminated, then the identity of the called party would have 
>> to be inferred from the R-URI. For instance in this case if the callee 
>> was identified by an assigned anonymous gruu, then the identity coming 
>> back would have that, which wouldn't be very useful.
>>
>>>>> From: Jonathan Rosenberg [mailto:[email-masked]] Sent: 
>>>>> Wednesday, September 27, 2006 12:50 AM
>>>>> To: IETF SIP List
>>>>> the gruu draft. Instead, a separate specification would be 
>>>>> developed which would allow for loose routing to apply to user 
>>>>> agents. So, consider a UA which registers. It would include a 
>>>>> contact and a Supported header field with the value "ua-route". The 
>>>>> registrar, assuming it understands this, notes that the UA supports 
>>>>> UA loose routing and stores the contact. When an incoming call 
>>>>> arrives for the AOR, rather than rewriting the R-URI with the 
>>>>> registered contact, it pushes the registered contact into a Route 
>>>>> header and leaves the R-URI alone (assuming the registered UA 
>>>>> it would help clarify when a request is retargeted (change in 
>>>>> R-URI) vs. when its just being delivered to the recipient (no 
>>>>> change in R-URI).
>>>>>
>>>>> Comments?
>>>>>
>>>>> -Jonathan R.
>>>>>
>>>>>
>>>>> --

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 5 Oct 2006 17:02:17 -0500

Right. If the P-Called can go away, great.

However, if we are trying to address a problem *like* P-Called, which
seemed to be a claim of the proposal, then it becomes important.
P-Called happened to be a convenient proxy for the discussion.

Regards,
Brian

> Sent: Thursday, October 05, 2006 4:39 PM
> To: Jonathan Rosenberg
> > I think there is a deeper question here about whether the calling 
> > party has a right to know the called party identity beyond the 
> > information revealed by the GRUU. If the GRUU is anonymous, 
> the caller 
> > only has the anonymous URI, and presumably this is because 
> the called 
> > party wanted to remain anonymous. Should then the P-CSCF 
> provide the 
> > actual called party identity to the caller after the call 
> completes? I 
> > would think this is a bad thing and a violation of privacy, no?
> 
> Well, the P-Asserted-Identity in the response is largely 
> there for use by servers in the trust domain. It can be 
> removed before it exits the trust domain, so that it isn't 
> made available to the caller, if desired. 
> But I don't think that is currently done, and in fact may 
> negate some of the intent of the feature. Typically it would 
> only be removed in the forward direction based on the 
> Privacy:id header. I don't think id privacy in the reverse 
> direction is supported, though perhaps it could be. That 
> might be the proper answer in this case.
> 
> It is a bit of a fuzzy area wrt the details of IMS, and in 
> large part is probably not an issue for ietf. Presumably IMS 
> can continue to use P-Called-Party-ID if they want to. And 
> *maybe* they will find that it is no longer needed. We just 
> don't know yet.
> 
> 	Paul
> 
> > -Jonathan R.
> > 
> > Paul Kyzivat wrote:
> >> translated, the P-Called-Party-ID header should be set to the AOR, 
> >> not the gruu.
> >>
> P-Called-Party-ID 
> >> to be inferred from the R-URI. For instance in this case if the 
> >> callee was identified by an assigned anonymous gruu, then the 
> >> identity coming back would have that, which wouldn't be 
> very useful.
> >>
> >> P-Called-Party-ID even after this change. That of course 
> is subject 
> >> to further consideration, but lets not count our benefits 
> until they 
> >> have been confirmed.
> >>
> >>     Paul
> >>
> >>>> routing mechanism used within the IMS core network to route 
> >>>> messages between various servers (x-CSCFs, BGCFs, App 
> Servers, etc).
> >>>> Although this may help with a number of issues, and on 
> the face of 
> >>>> it is a relatively simple idea (use a separate stack 
> data structure 
> >>>> for routing instead of a static URI) I don't think it solves all 
> >>>> the problems you may think it does.
> >>>>
> >>>> For instance, existing P-headers also have a trust-domain and 
> >>>> network assertion factor associated with them.
> >>>>
> >>>> Regards,
> >>>> Brian
> >>>>
> >>>>
> solution, 
> >>>>> contact and a Supported header field with the value "ua-route". 
> >>>>> The registrar, assuming it understands this, notes that the UA 
> >>>>> supports UA loose routing and stores the contact. When 
> an incoming 
> >>>>> call arrives for the AOR, rather than rewriting the 
> R-URI with the 
> and hand 
> >>>>> it out to some correspondent. When a correspondent 
> sends a request 
> >>>>> to that URI, it arrives at my home proxy. From there, since the 
> >>>>> R-URI is NOT rewritten, the entire URI, parameters and all, is 
> >>>>> passed to the UA. Thus, the UA knows the URI that was 
> >>>>> de-referenced. We wouldn't necessarily have to standardize a 
> >>>>> specific URI parameter, like grid, to carry the opaque data.
> >>>>>

---

From: [email-masked]
Date: Sun, 8 Oct 2006 14:20:45 -0400

This is all for the good, but may I suggest a couple of amendments?

One is to call it something other than "loose routing".  While it's
related to loose routing, it's not really the same thing.  The
essential functional difference is that the UA is able to recognize
that when a request's request URI is the UA's AOR, the UA is to
process the request, even though the rules of RFC 3263 do not specify
that the UA's host is a target for the request URI.

The other change is to reorganize how this information is presented to
the UA.  I think a change would make the mechanism both strictly
upward compatible with RFC 3261, and also more general and useful.

The RFC 3261 behavior is to remove the AOR from the request-URI and
replace it with the contact-address.  What you've suggested is to
leave the AOR as the request-URI and add a Route header containing the
hostpart of the contact-address.  As an alternative, consider putting
the contact-address in the request-URI and saving the AOR in a
parameter of the new Via header.

This method has a number of advantages, I think:

- It's strictly upward compatible with RFC 3261, so it requires no
  negotiation between UA and proxy/registrar.

- Since the full contact-address (not just its hostpart) is available
  in the request-URI on the hops from the proxy to the UA, there is no
  reduction in the information available for routing, which ensures
  that even the most complex current situations do not stop working.

That is "Nothing can possibly break."  (Unless an agent barfs on an
unknown Via parameter.)

- The UA can extract the information it needs -- "What variant of my
  GRUU was this request addressed to?" -- by scanning the Via headers,
  finding the first one with a "previous request URI" parameter", and
  checking that it is a GRUU for this contact-address.

- In the general case of messy routing, and where all proxies
  implement this mechanism, a full trace of address rewriting is
  preserved in the Via's.

The disadvantage is that this system might enlarge the Via's if it is
used for all routing/rewriting actions.  But if it is used only by
proxies when forwarding requests that are addressed to GRUUs, it
enlarges messages by about the same amount as your proposal.

(This is similar to e-mail Received headers, which now often contain a
"for" field giving the envelope address as seen by that host.)

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 8 Oct 2006 22:41:48 +0200

Isn't this a subset of History-Info?

Jeroen

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 9 Oct 2006 03:47:46 -0500

Thinking about this again from a different angle...

It seems to be that the crux of the proposal is to let the UAS know what
the request URI was at the time the UAS's proxy got ahold of the
request.

A few thoughts... 

First, what if the registrar wasn't integrated with the proxy? For
instance, if the registrar is also a separate location server apart from
the proxy, I think there's a problem. The proxy gets a request and needs
to resolve the next hop. It sends the request to it's location server,
which then sends back a 302 response to the request that the proxy uses
to route upon. In this case, the location server has no idea what the
requestor might do with the information, and the proxy has no idea it's
contacted a registrar. The proxy needed a route, and the location
server/registrar supplied them. How is the proxy to know not to rewrite
the URI? The 302 response could have returned anything, not just a
registered contact.

Second, how does the proposal differ from simply having the UAS's proxy
include a History-Info entry prior to swapping out the Request-URI with
the UAS contact? The UAS can then look at the History-Info entry for the
original URI.

Regards,
Brian

---

From: Dean Willis <[email-masked]>
Date: Mon, 9 Oct 2006 09:50:30 -0500

> the URI? The 302 response could have returned anything, not just a

The question you're asking: Is the operation of a proxy in processing  
a 302 response retargeting or rerouting?

I suspect it is usually rerouting, and therefore the request URI  
would not change.

I'm beginning to think that most of our proxy operations are  
rerouting, and we should only retarget when we're really intending to  
deliver the response to "somebody else".

That said, it seems there are times when a redirect response from a  
proxy means "Contact your target at this alternate location" and  
times when it means "Please try a different target". We don't  
currently have a way to differentiate these cases in the current spec.

Here's an off-the-wall proposal:

We could say that a 302 always indicates a "retargeting" action and  
that, for the sake of preserving response identity (that is,  
eliminated unanticipated response identity), it SHOULD be returned to  
the originating UA rather than acted on by a proxy.

We could also say that a 305 is always a rerouting action and MUST  
preserve the response identity, therefore it MAY be acted on by a proxy.

Then we'd set up most "location servers" to send 305 instead of 302.

> the UAS contact? The UAS can then look at the History-Info entry  

Frankly, I don't expect SBCs to correctly pass History-Info any more  
than they correctly pass Via headers. I do however expect them to  
correctly pass request URIs.

And with the idea of stacking "request parameters" in H-I or Via, we  
potentially get this awful situation where we have to figure out how  
to combine multiple parameters inserted in different places by  
different proxies. This doesn't occur, at least not the same way, if  
the only parameters examined by the UAS are those in the request URI.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 9 Oct 2006 10:59:31 -0500

> Sent: Monday, October 09, 2006 9:51 AM
> Cc: Jonathan Rosenberg; IETF SIP List; Juha Heinanen; 
> [email-masked]
> > instance, if the registrar is also a separate location server apart 
> > from the proxy, I think there's a problem. The proxy gets a request 
> > and needs to resolve the next hop. It sends the request to it's 
> > location server, which then sends back a 302 response to 
> the request 
> > that the proxy uses to route upon. In this case, the 
> location server 
> > has no idea what the requestor might do with the 
> information, and the 
> > proxy has no idea it's contacted a registrar. The proxy needed a 
> > route, and the location server/registrar supplied them. How is the 
> > proxy to know not to rewrite the URI? The 302 response could have 
> > returned anything, not just a registered contact.
> >
> 
> The question you're asking: Is the operation of a proxy in 
> processing a 302 response retargeting or rerouting?
> 
> I suspect it is usually rerouting, and therefore the request 
> URI would not change.

I suspect that you're right, but it doesn't have to be. Further, the
contact list could contain both endpoints to retarget to, and endpoints
to reroute to. I don't think we can safely apply the same logic to an
entire list of contacts and get a universally correct result.

> rerouting, and we should only retarget when we're really 
> intending to deliver the response to "somebody else".
> 
> That said, it seems there are times when a redirect response 
> from a proxy means "Contact your target at this alternate 
> location" and times when it means "Please try a different 
> target". We don't currently have a way to differentiate these 
> cases in the current spec.
> 
> We could say that a 302 always indicates a "retargeting" 
> action and that, for the sake of preserving response identity 
> (that is, eliminated unanticipated response identity), it 
> SHOULD be returned to the originating UA rather than acted on 
> by a proxy.
> 
> We could also say that a 305 is always a rerouting action and 
> MUST preserve the response identity, therefore it MAY be 
> acted on by a proxy.
> 

I doubt you can setup most location servers to send back a 305 instead
of a 302. I would imagine the return code is hard-coded. Also, your
response assumes that the contact list returned is homogenous: it's
either all retargets, or all reroutes. I don't believe that the current
specification has any such requirement on the 3xx contact lists, ie.
they could be heterogeneous lists.

> 
> > Second, how does the proposal differ from simply having the UAS's 
> > proxy include a History-Info entry prior to swapping out the 
> > Request-URI with the UAS contact? The UAS can then look at the 
> > History-Info entry for the original URI.
> 
> Frankly, I don't expect SBCs to correctly pass History-Info 
> any more than they correctly pass Via headers. I do however 
> expect them to correctly pass request URIs.

Oh, why limit your imagination of Murphy's Special Law of the SBC: if
can be mangled, it will be mangled. Seriously, that's the SBC's problem.
Fortunately, unlike user agents, they are relatively limited in number
and easier to fix when they're doing something bad.

Designing for an SBC is like designing a protocol around someone who
didn't read the RFC but instead Asked a Ninja how SIP worked (see
www.askaninja.com if you've not already been there).

I'd imagine most SBCs currently would only mangle an H-I out of random
funness. I doubt that they would otherwise bother with them.

> 
> And with the idea of stacking "request parameters" in H-I or 
> Via, we potentially get this awful situation where we have to 
> figure out how to combine multiple parameters inserted in 
> different places by different proxies. This doesn't occur, at 
> least not the same way, if the only parameters examined by 
> the UAS are those in the request URI.

I thought the request-URI was going to get left alone from the
originating UAC all the way to the UAS by the current proposal. What
scenario are you talking about?

Regards,
Brian

---

From: Dean Willis <[email-masked]>
Date: Mon, 9 Oct 2006 11:25:02 -0500

> entire list of contacts and get a universally correct result.

Two cliche responses:

1) Garbage in, garbage out

2) If it hurts, don't do it.

Mixed response sets (unless each response is individually marked) are  
guaranteed to mess up the anticipated response identity namespace and  
turn the whole situation into a Mulligan Stew of unidentifiable  
ingredients. Don't use them.

> they could be heterogeneous lists.

That would definitely be a change from current behavior. However, it  
would be a reasonably backward-compatible change, as it isn't going  
to make the situation any worse for existing already-broken systems.  
Furthermore, where redirect responses are processed by proxies, it  
has the advantage of not impacting UA specifications at all.

Where redirect responses are NOT handled by proxies, this approach  
preserves 302 processing as it currently works, and could also be  
expected to work reasonably well with naive 305 handling in an  
existing UA. Yes, such a naive UA (as I understand it, some UAs treat  
305 identically to 302) would end up retargeting when it could have  
simply rerouted, but the situation is still no worse than the current  
process.

An alternative (alluded to above) is that each element in a  
redirection set could be tagged as a reroute or retarget. This might  
be less backward compatible. Or maybe not, as it might end up as  
current 302 processing does and just treat everything as a retarget  
unless the tag is understood by the UAC.

> scenario are you talking about?

One variation of the proposal (and where H-I came into this thread)  
suggested continuing to rewrite the request URI in both rerouting and  
retargeting cases, but store the original request URI in a Via or H-I  
header field. The UAS would then work back up the Via or H-I stack to  
find the original parameters. I can readily imagine scenarios where  
several possibly conflicting parameters get inserted at different  
hops, thereby requiring the UAS to process through the whole Via or H- 
I stack and sort out the mess of parameters. I find this scenario  
unattractive.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 9 Oct 2006 11:51:29 -0500

> Sent: Monday, October 09, 2006 11:25 AM
> 
> >
> > contact list could contain both endpoints to retarget to, and 
> > endpoints to reroute to. I don't think we can safely apply the same 
> > logic to an entire list of contacts and get a universally correct 
> > result.
> >
> 
> Two cliche responses:
> 
> Mixed response sets (unless each response is individually 
> marked) are guaranteed to mess up the anticipated response 
> identity namespace and turn the whole situation into a 
> Mulligan Stew of unidentifiable ingredients. Don't use them.

But it didn't hurt until you started applying this new logic. I think
that's what we call in the trade: not backwards compatible.

I guess we can say: considered, not going to deal with it. However,
given that an endpoint could have contacted a location server that isn't
compliant to this spec, what I'm still struggling with is how the UA
knows that what it got in the request-URI is what it thinks it is just
because the last guy on the proxy chain put a route header in there.

I've been bringing up various scenarios where there (to me) is a
reasonable degree of "Yeah, that can happen and it'll change the request
URI before we get to a proxy that supports the mechanism we're
describing". I haven't gotten a satisfying response to these scenarios,
and I do think it matters because these are scenarios that are going to
break what you're trying to accomplish. They need to be handled
deterministically and detectably in a backwards compatible manner
because it's the older version element that's going to break you.

> One variation of the proposal (and where H-I came into this 
> thread) suggested continuing to rewrite the request URI in 
> both rerouting and retargeting cases, but store the original 
> request URI in a Via or H-I header field. The UAS would then 
> work back up the Via or H-I stack to find the original 
> parameters. I can readily imagine scenarios where several 
> possibly conflicting parameters get inserted at different 
> hops, thereby requiring the UAS to process through the whole 
> Via or H- I stack and sort out the mess of parameters. I find 
> this scenario unattractive.

I still don't understand. I thought we wanted the UAS to get the
original request-URI specified by the UAC. Nothing bolted on or
added/subtracted. The UAS should be able to simply look at the oldest
H-I header and read off the captured request-URI value. I think that
only one H-I header even needs to be captured by the first guy to try to
change the request-URI.

I'm still trying to figure out what the salient difference is here
between this and the proposal, especially given that H-I seems a lot
less likely to be broken by elements that are ignorant of the proposal.

Regards,
Brian

---

From: Dean Willis <[email-masked]>
Date: Mon, 9 Oct 2006 12:10:37 -0500

> that's what we call in the trade: not backwards compatible.

So you've solved response identity with the current logic? I don't  
think so.

Given that the new logic's primary benefit is to fix the  
unanticipated response problem for "new logic" systems and make  
nothing worse when operating in "backward compatible" mode, I think  
we're ok.

> because the last guy on the proxy chain put a route header in there.

huh?

> because it's the older version element that's going to break you.

I think we're failing to communicate.

At the very best and very west, you have a request URI delivered to a  
UAS. The UAS has to deal with that request URI. if there are  
parameters there that are meaningful, it has parameters to work from.  
If there aren't it doesn't. Systems cursed with current-edition  
broken retargeting just aren't going to be able to use the new  
mechanism, but that doesn't mean they work any worse (or any  
differently) from how they already work.

My definition of "backward compatible" does NOT mean that the new  
features will work on old nodes. It means that the new features will  
not interfere with old nodes.

> only one H-I header even needs to be captured by the first guy to  

What if the request URI got changed twice? This happens fairly  
frequently.

Or what if there's another proxy between the proxy-that-does-contact- 
routing and the UAS, and that second proxy inserts an H-I for other  
purposes?

What if there are 14 H-I records, all of which have stored parameters?

> less likely to be broken by elements that are ignorant of the  

H-I seems to me to be a lot less likely to produce a useful result.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Oct 2006 13:25:40 -0400

Regarding mixed retargetting and rerouting in the same 3xx:

I don't see much of an incompatibility issue. Right now, when 302 is 
acted upon by proxy recursion it is always retargetting. So anybody 
expecting rerouting has been out of luck. If it was acted upon by the 
UAC, then it might be handled either as retargetting or rerouting, but 
the sender of the 302 can't predict which it will be. So at best it is 
currently handled as Dean proposes, and at worst it is handled in a 
totally unpredictable manner. Dean's proposal would improve the situation.

In the case of 305 there are so many ambiguities and uncertainties about 
how it should work that in a practical sense it is unusuable. If this 
gave a well defined meaning to 305 it would again improve the overall 
situation.

Incorporating 305 into this overall picture of distinguishing 
retargetting from rerouting is intriguing, and can help in making 305 
usable. It does however raise some interesting issues. Suppose for now 
that a proxy for example.com is processing a request with R-URI of 
sip:[email-masked], and there is one registered contact, for 
sip:alice.example.com;lr:

- first the proxy appends 'Route: sip:alice.example.com;lr' after
   any existing route headers

- if the proxy receives a 305 with 'Contact: ep.example.com;lr',
   what does that mean about how the next try is constructed?
   . is it by appending
     'Route: sip:ep.example.com;lr;sip:alice.example.com;lr'
     to the original request?
   . or is it by appending only
     'Route: sip:ep.example.com;lr'
     to the original request.

I think both answers are reasonable under different circumstances. In 
the example given above, the first answer is probably the right one. But 
if the returned contact were 'sip:bob.example.com;lr' then the second 
answer would probably be correct.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 9 Oct 2006 12:39:24 -0500

Major snip. Resetting. 

> Sent: Monday, October 09, 2006 12:11 PM
>

Yes, but perhaps we're generating a lot of great text for a draft. Let
me try again.

Current proposal: 
- Last hop adds a Route with the contact in it, leaves the request-URI
alone. UAS inspects request-URI for parameters.

Alternate proposal:
- Last hop adds a H-I header, otherwise follows RFC-3261. UAS inspects
H-I header for parameters.

To me, it's a matter of what header type you're adding and how much you
expect elements to do to support the mechanism. So why is one superior
to the other?

You are correct though, I've been using the wrong term by talking about
backwards compatibility. I'm concerned about FORWARD compatibility:
essentially if the new mechanism isn't deterministic and can't at least
detect the presence of old nodes mucking about with the request-URI when
we're not expecting them to, then it seems somewhat limited in value. If
the proposal at least had a detection mechanism as to when the
request-URI had been messed with I'd be a lot happier.

Regards,
Brian