Subject: [Sip] Error reporting in caller prefs

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 27 Jan 2003 14:27:17 -0500

This is the second note of two that describes some recently encountered
issues while trying to wrap caller prefs.

The issue here is error reporting.

Lets say a caller lists a bunch of caller preferences, which include
Reject-Contacts and Require-Contacts (now removed in -08 and replaced
with a require parameter on Accept-Contact, but I'll use the -07 
terminology). It is entirely
possible that these preferences will result in ALL registered contacts
getting discarded. The current behavior will be that the proxy acts as
if there were no registered contacts, and returns a 480. Now, this means
that the caller has no way to determine if the request failed because of
their preferences, or because there really were no registered contacts.

At first, I thought that this was a bad thing. But, thinking abuot it
more, I concluded it was a good thing, for privacy reasons. The proxy is
the one performing the caller preferences computation. The proxy will
frequently not be the one authenticating the caller, or authorizing them
to make calls or learn information abuot the called party. But, if a
proxy reported information on call failures because of preference
mismatches, a client would be able to "probe" the network using caller
preferences, and learn detailed ifnormation on the capabilities of the
devices associated with a user, without authentication. The current
behavior prevents that, and I think thats good.

OK, so whats the problem? Well, its those implicit preferences again.
Lets say a user sends a SUBSCRIBE request, without caller preferences
parameters. The called party has one UA, and it doesnt support
SUBSCRIBE. Its registration to its proxy indicated such. The proxy
supports caller preferences. So, it wuold compute an implicit preference
to route the request to a UA that supports SUBSCRIBE, and give it the 
require strength (meaning, contacts which don't support SUBSCRIBE are 
discarded). Since none do, the
one registered contact is discarded, and the caller receives a 480.

A similar thing happens for event packages.

This is a change in behavior if caller preferences were not used, in
which case either (1) the UAS would authenticate and authorize the
caller, and then return a 405 with the allowed methods, (2) the UAS
would not authenticate or authorize the UAC, and thus genreate a 403 or 401.

As a result, even though the caller did not use caller preferences, they
have suffered from a loss of information, just because the proxy used
caller prefs. The 405 would be useful for the UAC to perhaps try another
method, or report the failure to the user. I dont mind a loss of
information with EXPLICIT preferences, since the caller knows what they
are getting into. But for implicit, we shouldn't be changing basic SIP
behavior as seen by the UAC.

There are a small number of solutions:

1. eliminate Require-Contact entirely (or, in -08 terms, eliminate the 
require parameter to Accept-Contact). This solves the problem, because 
the proxy will simply set the un-matching contacts to have a q-value of 
zero, and try them last. In the above example, the one registered 
contact remains with q=0, and is tried, resulting in a 405.

2.eliminate implicit preferences that use the Require-Contact semantic.
So, if the request fails with a 480, its because the client explicitly 
asked for  soemthing they couldnt get.

3. If a proxy uses caller prefs, and the result is the eliminatin of all 
contacts, AND if the reason they were eliminated was that there was an 
implicit Require-Contact for a specific method or event package, the 
proxy generates a 405 or 489 as if it were the UAS.

4. modify the semantics of require-contact so that, in the case where
all contacts would be eliminated, instead of eliminating them, it sets
the q-value to zero. This avoids the error condition.

I didn't see any other approaches. None of these seem perfect:

1. Approach 1 is a non-starter; we have applications which need the 
Require semantic.

2. Approach 2 is better than approach 1. However, it will result in 
SUBSCRIBE and other methods being sent to a UAS that indicated that it 
didn't support those methods. On the list, Juha had complained loudly 
about this, and this thread was one of the motivations for adding 
require-contact. Now, the client can add the explicit Require-Contact 
with this solution, but that adds somewhat of a burden.

3. Appraoch 3 has a potential security issue. The proxy will generate a 
405 or 489 on behalf of the UAS. So, if the UAS would generally not want 
to reveal this information (supported methods and event packages) unless 
the UAC would be authorized and authenticated, this approach will "leak" 
this information. One might argue that if the UAS uses caller prefs, and 
tells the proxy which methods and event packages it supports, it has 
forfeited its right to explicitly authenticate and authorize the caller 
before this information is divulged. If the UAS has these privacy 
concerns, it should not register these caller preferences parameters.

4. Approach 4 has similar problems to approach 2.

I am inclined to go with approach 3, adding the appropriate discussions 
on the privacy considerations. The specific algorithm I would propose is 
this. If the caller prefs selection process results in zero contact, the 
proxy re-runs the algorithms without the implicit preferences. If now, 
there are contacts remaining, it concludes that the implicit preferences 
caused the problem. It then checks to see if the problem was methods or 
event packages, and generates a 405 or 489 accordingly.

Comments?

-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

_______________________________________________
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: Mon, 27 Jan 2003 15:33:46 -0600

> event packages, and generates a 405 or 489 accordingly.

Two comments; one con, one "interesting":

1. It seems to me that this approach adds a substantial burden
   to the proxy.

2. This has the interesting effect of forcing the proxy to
   aggregate the methods and the event-packages
   available for an address-of-record. (e.g. if I have
   a client registered that supports MESSAGE,
   and one that supports INVITE, the proxy-generated
   405 will ostensibly indicate both INVITE and MESSAGE
   as acceptable methods.) Of course, this may well exacerbate
   the security problems you discuss -- but it also might
   be a useful feature. It also has the odd consequence that
   I can get a more accurate picture of your capabilities
   by intentionally sending an invalid method than
   I can by sending an OPTIONS...

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Jan 2003 19:33:17 -0500

inline.

> 1. It seems to me that this approach adds a substantial burden

Well, its definitely more than zero. Caller prefs as it stands is, by 
definition, something a proxy spends cycles doing. How much more it will 
take to add this piece of processing, I am not certain.

>    I can by sending an OPTIONS...

Interesting indeed.

I would rather not reveal information which would otherwise not be 
revealed. I'd propose that the proxy reveal only the supported methods 
of the UA that would have otherwise received the request.

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 28 Jan 2003 18:06:41 -0800

Hi,

I vote for option 4 with a subtle variation.  Accept-contact w/ require 
will still match contacts (with q=0) if all the explicit preferences 
match but the implicit ones do not.  The difference is that you still 
get a 480 if you eliminated all contacts using an *explicit* match, but 
an ordinary 405 or 489 if all contacts were eliminated using implicit 
preferences only.

thanks,
-rohan

On Monday, January 27, 2003, at 11:27 AM, Jonathan Rosenberg wrote:

> the proxy will simply set the un-matching contacts to have a q-value 
> of zero, and try them last. In the above example, the one registered 
> 3. If a proxy uses caller prefs, and the result is the eliminatin of 
> all contacts, AND if the reason they were eliminated was that there 
> was an implicit Require-Contact for a specific method or event 
> package, the proxy generates a 405 or 489 as if it were the UAS.
>
> 3. Appraoch 3 has a potential security issue. The proxy will generate 
> a 405 or 489 on behalf of the UAS. So, if the UAS would generally not 
> want to reveal this information (supported methods and event packages) 
> unless the UAC would be authorized and authenticated, this approach 
> will "leak" this information. One might argue that if the UAS uses 
> caller prefs, and tells the proxy which methods and event packages it 
> supports, it has forfeited its right to explicitly authenticate and 
> authorize the caller before this information is divulged. If the UAS 
> has these privacy concerns, it should not register these caller 
> preferences parameters.
>
> I am inclined to go with approach 3, adding the appropriate 
> discussions on the privacy considerations. The specific algorithm I 
> would propose is this. If the caller prefs selection process results 
> in zero contact, the proxy re-runs the algorithms without the implicit 
> preferences. If now, there are contacts remaining, it concludes that 
> the implicit preferences caused the problem. It then checks to see if 
> the problem was methods or event packages, and generates a 405 or 489 
> accordingly.
>
> Comments?
>
> -Jonathan R.
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Jan 2003 15:11:32 -0500

> an ordinary 405 or 489 if all contacts were eliminated using implicit 

I don't quite follow the second sentence above, but I do understand the 
desired property in the third. Indeed, in my analysis below, I had 
simply declared approach 4 as being the same as 2, but its not so. In 
the case where there is at least one matching contact, approach 4 will 
make sure that implicit preferences are honored at require strength, so 
that a UA which doesn't support SUBSCRIBE never gets one if there is a 
UA that does, for example. The only case that a UA will get a method it 
doesnt support is when none of the registered contacts support that 
method. I think thats actually a reasonable compromise. It also has less 
burden on proxies than my original proposal to go with option 3.

So, I am now inclined to agree with Rohan and go with option 4.

-Jonathan R.