[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Error reporting in caller prefs
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:jdrosen@dynamicsoft.com]
> Sent: Monday, January 27, 2003 9:27 PM
> To: sip@ietf.org
> 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
> jdrosen@dynamicsoft.com 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip