Subject: [Sipping] New I-D on URI leasing

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Feb 2003 01:07:49 -0500

Folks,

I've just submitted an I-D on the concept of "URI leasing". THis is my 
proposed technique for solving the "globally routable UA URI" problem. 
SPecifically, for cases like REFER, how do we construct a URI that 
routes to a specific UA instance in a domain? At the last ietf meeting, 
this issue came up in several contexts. I suggested a single document to 
explore the problem. The chairs asked for volunteers, and I said I'd 
write one, time permitting, if no one else stepped up. Since no one did, 
well, here it is.

Until it appears in the archives, you can pick it up at:
http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.txt
http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.html

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 12 Feb 2003 10:07:05 -0600

Hi Jonathan,

This is a useful discussion of the problem of constructing globally 
routable Contact URIs.

However, if you re-read 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-00.txt 
you will see that your proposed solution is almost identical to the "device 
AOR" proposed in Section 7.5, with the exception of the LEASE method, 
which, as you mention can (and perhaps should) be done outside of SIP.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

At 01:07 AM 2/12/2003 -0500, Jonathan Rosenberg wrote:
>SPecifically, for cases like REFER, how do we construct a URI that routes 
>to a specific UA instance in a domain? At the last ietf meeting, this 
>issue came up in several contexts. I suggested a single document to 
>explore the problem. The chairs asked for volunteers, and I said I'd write 
>one, time permitting, if no one else stepped up. Since no one did, well, 
>here it is.
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 12 Feb 2003 20:05:38 -0600

Just to clarify and expand on my earlier short comments...

I'm not unhappy that the solution proposed in the draft  is similar to the 
one discussed in cc-transfer.   The method does work,  and we can  discuss 
whether it should be two REGISTERs or one LEASE and one REGISTER.  However, 
both approaches are multi-step, which others objected to when it was 
discussed at IETF-55.

I had hoped that a new proposal was coming, or a way to make Rohan's 
escaped Route header in a Contact work.    This approach, (4.4 in this 
draft) does not actually suffer from the problems listed - if multiple 
proxies must be traversed, multiple URIs can be escaped into the Route 
header.  The real problem with this approach is that it violates Table 1 in 
RFC 3261 so would be ignored by all RFC  3261 compliant UAs.  The backwards 
compatibility problem with pre-bis-04 UAs is even worse.  Since under the 
old Record-Route rules the Contact is included in the Route header, you 
could potentially have a URI in a Route header with  an escaped Route 
header - yuk!  However, there might be a clever solution to work around 
this problem.  This is the only solution that I know of that meets REQ-8.

REQ-9 is a bit strange - the anonymity of a Contact is a very small part of 
the total anonymity  picture.   It seems this requirement could simply be 
met by having the user portion  of the Contact be a random string.  The 
privacy discussion in 4.2 about the call center operator is simplistic - 
for privacy, much more than just fixing Contact is required and would be 
used in practice.

I'm not sure understand the motivation for REQ-11.  I don't know why a UA 
would want to generate a unique Contact for each dialog - it seems like 
quite a burden on the UA and a difficult requirement for a solution to 
meet.  It seems like there is some sort of security  reason for this, but 
it is not stated.

One minor correction - the transfer problem is with  attended transfer 
only, not blind transfer or transfer in general.

As this is an important topic for many  applications, it is important that 
we get some good discussion going on the requirements and possible solutions.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Feb 2003 02:54:51 -0500

Alan Johnston wrote:
> I'm not unhappy that the solution proposed in the draft  is similar to 
> the one discussed in cc-transfer.   The method does work,  and we can  
> discuss whether it should be two REGISTERs or one LEASE and one 
> REGISTER.  However, both approaches are multi-step, which others 
> objected to when it was discussed at IETF-55.

I don't see a problem in adding steps if its done asynchronously with 
calls. That is, with the mechanism I discuss, you would be allocated a 
namespace from which you can choose URI. THerefore, for each call, there 
is zero additional protocol operations needed.

> escaped Route header in a Contact work.

I'm not sure whether you are trying to imply that there is nothign new 
in my draft?

> This approach, (4.4 in this 
> header. 

How does a UA learn the route headers to include? If you say that they 
are taken from the route set of the dialog, then how does a UA know 
which ones need to be included? How does a UA know whether a different 
caller is supposed to use that same set of proxies? The route set from 
the dialog is also purposefully scoped to that dialog, so that proxies 
can include information in it that is related to the dialog. So, would a 
UA discard that user part? The URI might not work without that. A smart 
proxy that embeds dialog information in the user part, so that it can 
reject calls with route headers it never generated, would cause that to 
fail.

> The real problem with this approach is that it violates Table 1 
> in RFC 3261 so would be ignored by all RFC  3261 compliant UAs. 

There are some additional problems, as above.

> The 
> backwards compatibility problem with pre-bis-04 UAs is even worse.  
> Since under the old Record-Route rules the Contact is included in the 
> Route header, you could potentially have a URI in a Route header with  
> an escaped Route header - yuk!  However, there might be a clever 
> solution to work around this problem.  This is the only solution that I 
> know of that meets REQ-8.

No, thats not true. The mechanism I proposed, if the lease and register 
operations are combined, can be made to work without network state.

> 
> REQ-9 is a bit strange - the anonymity of a Contact is a very small part 
> of the total anonymity  picture. 

We have already discussed, in the context of rfc3323, several different 
notions of what encompasses privacy. This requirement is meant to rule 
out solutions that, for example, would require the user's AOR to be used.

   It seems this requirement could
> simply be met by having the user portion  of the Contact be a random 
> string. 

Yes.

  The privacy discussion in 4.2 about the call center operator is
> simplistic - for privacy, much more than just fixing Contact is required 
> and would be used in practice.

As I mentioned, there are various levels of privacy that we have 
recognized as useful.

> 
> I'm not sure understand the motivation for REQ-11.  I don't know why a 
> UA would want to generate a unique Contact for each dialog - it seems 
> like quite a burden on the UA and a difficult requirement for a solution 
> to meet.  It seems like there is some sort of security  reason for this, 
> but it is not stated.

This is what I had in mind. You and I are talking. I want to transfer 
you to Robert. You don't want anyone to generally be able to call your 
device - they should go through your normal SIP AOR that identifies you 
as a user. However, for the transfer to work, I need a URI for your 
device. If you could create those contact URIs, you could create one 
that contains a hash of the dialog ID with me, or a timestamp embedded. 
This way, if you should receive an INVITE to that URI, you could check 
it to make sure it still valid. If not, you reject the INVITE.

> only, not blind transfer or transfer in general.

Yes, that is right. My error.

-Jonathan R.

---

From: Alan Johnston <[email-masked]>
Date: Fri, 14 Feb 2003 16:33:38 -0600

At 02:54 AM 2/14/2003 -0500, Jonathan Rosenberg wrote:

>>REGISTER.  However, both approaches are multi-step, which others objected 
>>to when it was discussed at IETF-55.
>

>I'm not sure whether you are trying to imply that there is nothign new in 
>my draft?

Of course not.

>>This approach, (4.4 in this draft) does not actually suffer from the 
>>problems listed - if multiple proxies must be traversed, multiple URIs 
>>can be escaped into the Route header.
>
>How does a UA learn the route headers to include? If you say that they are 
>taken from the route set of the dialog, then how does a UA know which ones 
>need to be included? How does a UA know whether a different caller is 
>supposed to use that same set of proxies? The route set from the dialog is 
>also purposefully scoped to that dialog, so that proxies can include 
>information in it that is related to the dialog. So, would a UA discard 
>that user part? The URI might not work without that. A smart proxy that 
>embeds dialog information in the user part, so that it can reject calls 
>with route headers it never generated, would cause that to fail.
>

The Route URI wouldn't be extracted from a dialog, it would have to be 
learned or provisioned similar to a pre-loaded Route URI. The Route header 
used also would be similar to a pre-loaded Route in that it would never 
contain any specific dialog information.

Think of how a normal user's AOR is routed.  Usually, a DNS SRV lookup (or 
similar) is performed on the host name which initially routes the request 
to a set of proxies.  These proxies then take care of all the routing 
between the proxy and the endpoint.  If multiple proxies need to be 
traversed, the proxy first proxy inserts them.   All an embedded Route 
header in a Contact needs to do is to cause essentially the same DNS 
lookups to occur so the request reaches the same initial set of 
proxies.  This another way of stating your requirement that the device URI 
be in the same domain as the AOR URI for the user - they must resolve to a 
similar set of proxies, unless the topology is trivial in which case it 
doesn't matter.

>>The real problem with this approach is that it violates Table 1 in RFC 
>>3261 so would be ignored by all RFC  3261 compliant UAs.
>
>>The backwards compatibility problem with pre-bis-04 UAs is even worse.
>>an escaped Route header - yuk!  However, there might be a clever solution 
>>to work around this problem.  This is the only solution that I know of 
>>that meets REQ-8.
>

There is still a binding between the device URI template and the device 
itself.  Regardless of whether this is done through a REGISTER or a LEASE, 
it is still state information and is effectively the same as a registration.

>notions of what encompasses privacy. This requirement is meant to rule out 
>solutions that, for example, would require the user's AOR to be used.

The use of the user's AOR is already ruled out by the most important 
requirement that it resolve uniquely to a device without forking.  By the 
way, that requirement is mentioned in the definition section 2 but not in 
the requirements section 6.  A user's AOR in a Contact would also cause all 
sorts of other problems with respect to forking of re-INVITEs, etc.

>>simply be met by having the user portion  of the Contact be a random string.
>
>Yes.
>
>This is what I had in mind. You and I are talking. I want to transfer you 
>to Robert. You don't want anyone to generally be able to call your device 
>- they should go through your normal SIP AOR that identifies you as a 
>user. However, for the transfer to work, I need a URI for your device. If 
>you could create those contact URIs, you could create one that contains a 
>hash of the dialog ID with me, or a timestamp embedded. This way, if you 
>should receive an INVITE to that URI, you could check it to make sure it 
>still valid. If not, you reject the INVITE.

Usually, the use of a Contact URI is involves in a dialog.  For example, in 
an attended transfer, there is a Replaces header.  The UA then knows which 
dialog is being replaced - there is no requirement for the Contact to be 
limited to the duration of the dialog - the rejection is based on the 
Replaces header and whether the requester is permitted to replace 
dialogs.  The same thing for a conference - the focus will know if the 
conference is still valid and whether the requester may join based on the 
conference policy for that URI - not based on the URI itself which just 
references the conference instance.

In SIP, we have always said that a Contact URI may not be valid outside the 
dialog.  It has never been a requirement that it never be valid outside a 
dialog.  I'm still not seeing enough justification for this requirement - 
seems like a lot of pain for little gain, but I'd be interested in other's 
opinions.  If this requirement could be met easily, I'd be happy with it, 
but it introduce a whole set of name space requirements on a UA - seems 
like a lot of complexity.