Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202)

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2001 17:01:59 -0500

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 12:53 PM
> To: [email-masked]'
> Subject: [Simple] Reacting to multiple sources of presence data (was
> 200v202)
> 
> Given that:
> 
> * A SUBSCRIBE may fork
> * Multiple endpoints may accept the SUBSCRIBE
> * These notifying endpoints may not have identical
>   presence documents to provide
> 
> The root problem is:
> * How do we reconcile the different documents?

Yes, that is the essence of the problem.

> 
> There have been a handful of proposed solutions, each
> bringing their own set of additional problems. I think
> these two capture the main flavors of the proposals:
> 
> 1) Accept only the notifier who's 2xx was chosen by
>    the proxy mesh to be forwarded to the subscriber.
>    Ignore input from all other notifiers.
>    Rely on configuration of all the elements to provide
>    the "right" presence document.
>    (I think this is the currently documented solution)
>    Problems: 
>      * Doesn't allow state aggregation (but maybe that
>        should be a domain-specific application and not
>        something we try to do generically in protocol)

Another problem I pointed out is that the 2xx which was "chosen by the proxy
mesh" may be a 202, and later be rejected, whereas one of the 2xx which was
not chosen, is later accepted. However, its NOTIFY is discarded.

> 
> 2) Accept all notifiers by springing subscriptions into
>    being on receiving NOTIFYs with matching dialog identifiers
>    (but unknown to-tags). Each such subscription exists 
>    independently of the others, with its own lifetime and 
>    route-set. Rely on configuration of all the elements
>    to provide the "right" set of notifiers.
>    Problems:
>      * How do you resolve conflicts during state composition?
>      * Is the DoS opportunity this creates acceptable?

I'm not sure I understand the DoS opportunity. Can you elaborate?

>      * The configuration necessary to reach the "right" set
>        is very restrictive. (For instance, all the notifiers
>        must be behind the same number of challenging proxies).

I don't see that at all. What has the number of proxies got to do with it?

-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

---

From: Brazier Lachlan <[email-masked]>
Date: Tue, 13 Nov 2001 09:03:56 +0100

Hmm,

would it help to ignore the To-tag and include a new Header, lets say
something like "NOTIFY-ID", and mandate, that the NOTIFY-ID MUST be the same
for all clients who want to act as PA for a url. 

I think this could work, because any client acting as PA actually needs the
information that it can act as a PA for a given url.
This would also allow a user to genereate it's own "code" to avoid being
used as DoS launcher. Moreover, when the presentity goes on holiday, it can
tell it's collegue, partner etc. the code. As the "code" is user defined,
the "code" can be changed whenever necessary. Even better, as it is a new
Header, you can encrypt your "code".

Is this any good??

Cu 
Lachlan

-----Originalnachricht-----
Von: Robert Sparks
An: Jonathan Rosenberg; [email-masked]'
Gesendet: 12.11.01 23:18
Betreff: RE: [Simple] Reacting to multiple sources of presence data (was 2
00v202)

inline

> Another problem I pointed out is that the 2xx which was 
> "chosen by the proxy mesh" may be a 202, and later be 
> rejected, whereas one of the 2xx which was not chosen, is 
> later accepted. However, its NOTIFY is discarded.

I don't understand this scenario yet. What does it mean to be
later rejected or accepted?

> I'm not sure I understand the DoS opportunity. Can you elaborate?

Assume you subscribe to me, and for some reason I decide to
take your client down. All I need to do is send some number
of NOTIFYs with different To: tags (preferably with very large
route-sets that you now have to maintain), continuing until you
run out of memory and die. This will require far less effort on
my part than simply trying to flood your network connection.

> I don't see that at all. What has the number of proxies got 

Consider the following topology

                  notifier 1
                 /
subscriber --- P1
                 \
                  P2 - notifier 2

Where P2 issues a 407. If notifier 1 issues a 2xx, you will
never be able to get presence information from notifier 2 -
you will never see its challenge. If you needed the information
from both notifer 1 and notifier 2 in order to be correct, the same
number of challenging proxies would have to exist on the path
from subscriber to notifier 1 and the path from subscriber to
notifier 2, or one of them will be left out in the cold. 

RjS

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Nov 2001 14:03:55 -0500

Elaborate.

(note that the subscription is legitimate - if I can provide
credentials that you will accept for one notify, I can provide
them for N notifies).

RjS

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 11:25 AM
> To: 'Robert Sparks'; Jonathan Rosenberg; 
> Subject: RE: [Simple] Reacting to multiple sources of 
> presence data (was
> 2 00v202)
> 
> 
> Authentication.
> /a