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

From: Robert Sparks <[email-masked]>
Date: Mon, 12 Nov 2001 17:18:52 -0500

inline

> > 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.

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

> 
> > 
> > 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?

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.

> 
> >      * 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?

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

---

From: "James Undery" <[email-masked]>
Date: Tue, 13 Nov 2001 10:26:55 -0000

inline

> later rejected or accepted?

The scenario is subscription pending subject to authorisation, which may
result in rejection or acceptance.

> my part than simply trying to flood your network connection.

This problem exists in a different form in case 1, where, I return a fake
200 with my own tag in the 200. You will never get a NOTIFY with a matching
tag and it requires far less effort to prevent any of your subscriptions
succeeding (perl and netcat stand a good chance of beating legitimate
replies).

Limiting the number of NOTIFIYs you accept for a given subscription is a
simple way to limit your DoS attack for case 2 to being effective as the one
I described above for case 1.

> notifier 2, or one of them will be left out in the cold.

These issues have also been discussed on the SIPPING list, my proposed
solution was to add an additional header to the NOTIFY that indicated
subscription state. This helps with the 200 vs 202 issue and has an added
bonus. If the state allows unauthenticated the subscription can be reissued
to the notifier directly (using the route set) and individual subscriptions
authenticated regardless of other notifiers returning 2xx.

James

---

From: [email-masked]
Date: Tue, 13 Nov 2001 11:25:09 -0600

> From: Robert Sparks [mailto:[email-masked]]
>

Authentication.

/a