Subject: RE: [Sip] Error reporting in caller prefs

From: [email-masked]
Date: Tue, 28 Jan 2003 14:37:06 +0200

Can all this be fixed with a Require/Supported tag indicating that a UA understands the caller preferences extensions? Basically eliminating implicit preferences.

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, January 27, 2003 9:27 PM
> To: [email-masked]
> Subject: [Sip] Error reporting in caller prefs
> 
> 
> 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
> 
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Jan 2003 18:08:02 -0500

Implicit preferences has the benefit that it requires only one "side" to 
support it - the UAS and its proxy. Thus, if the terminating domain 
desires that SUBSCRIBE requests are routed to the PCs and not to the 
phones, it can do that by deploying caller prefs without the 
subscriber/watcher domain deploying it. This particular feature of 
caller prefs - only routing requests to UAs which support that method, 
is particularly useful. There was a long thread on the list about this 
feature, with some strong advocates behind it.

-Jonathan R.

[email-masked] wrote:
 > Can all this be fixed with a Require/Supported tag indicating that a
 > UA understands the caller preferences extensions? Basically
 > eliminating implicit preferences.
 >
 > Regards, Hisham
 >
 >
 >> -----Original Message----- From: ext Jonathan Rosenberg
 >> [mailto:[email-masked]] Sent: Monday, January 27, 2003
 >> 9:27 PM To: [email-masked] Subject: [Sip] Error reporting in caller
 >> prefs
 >>
 >>
 >> encountered issues while trying to wrap caller prefs.
 >>
 >> 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
 >> 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.
 >>
 >> 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.
 >>
 >> 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.
 >>
 >>
 >>
 >>  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.
 >>
 >> 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
 >> 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
 >>
 >
 >