Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2001 00:21:31 -0500

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 4:07 AM
> To: Jonathan Rosenberg
> Cc: 'Adam Roach (EUS)'; Ben Campbell; Robert Sparks; 'Christian
> Huitema'; [email-masked]'
> Subject: [Simple] DoS from rejected subscriptions (was Replacing the
> QAUTH concept)
> 
> 
> I've changed the subject as this is an important, separate issue.
> 
> Jonathan Rosenberg wrote:
> 
> >
> > -----Original Message-----
> > >From: Adam Roach (EUS) [mailto:[email-masked]]
> > >Sent: Thursday, March 15, 2001 7:20 PM
> > >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; 
> Robert Sparks
> > >Cc: 'Christian Huitema'; [email-masked]'
> > >Subject: RE: Replacing the QAUTH concept (was [Simple] 
> SIMPLE BoF agenda)
> > >
> > >
> > >> -----Original Message-----
> > >> From: Jonathan Rosenberg [mailto:[email-masked]]
> > >>
> > >> > From: Ben Campbell
> > >> >
> > >> > I would be somewhat concerned about a server keeping state
> > >> > for rejected subscriptions. That sounds like an opening for a
> > >> > DoS attack.
> > >> >
> > >>
> > >> Well, pending transaction state is even worse, if you think
> > >> about it. I
> > >> don't see any way around keeping pending transaction state. I
> > >> suppose you
> > >> could introduce restrictions like, no more than 50 pending
> > >> subscriptions for
> > >> one presentity at a time. This should cover the majority 
> of normal use
> > >> cases, and allow the server to drop pending subscriptions
> > >> associated with
> > >> attacks.
> > >Couldn't we retain only *one* "pending" or "rejected" transaction
> > >per each authenticated user (subscriber) per presentity? (and, of
> > >course, *no* state for unauthenticated users). Or is it too much
> > >to ask that the subscribing entity have a relationship with the
> > >server?
> >
> > No, I don't think thats sufficient. THe problem is that an 
> attacker might be
> > able to obtain a large number of authentic (but anonymous) 
> accounts (think
> > yahoo mail), and use those to launch attacks.
> 
> This can be solved with a change to the way SUBSCRIBE works, 
> basically the 202
> response only returns contacts present in the SUBSCRIBE. That 
> way the presence
> server only needs to use the SUBSCRIBE to generate the 
> response and the NOTIFY
> and doesn't need to store state about the SUBSCRIBE. (200s 
> are unaffected)
> 
> Comments gratefully received

I'm not following you. What has contacts in the SUBSCRIBE got to do with it?
How do you avoid the need to store pending subscription state in the case
where this is a legitimate subscription?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "James Undery" <[email-masked]>
Date: Tue, 20 Mar 2001 14:32:11 -0000

>From: Jonathan Rosenberg <[email-masked]>
>To: "'James Undery'" <[email-masked]>,        Jonathan Rosenberg  
><[email-masked]>
>CC: "'Adam Roach (EUS)'" <[email-masked]>,        Ben Campbell  
><[email-masked]>,        Robert Sparks 
><[email-masked]>,        "'Christian Huitema'" 
><[email-masked]>,        "[email-masked]'" 
><[email-masked]>
>Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q 
>AUTH concept)
>Date: Tue, 20 Mar 2001 00:21:31 -0500
>MIME-Version: 1.0
>Received: from [194.202.146.92] by hotmail.com (3.2) with ESMTP id 
>MHotMailBC80337D009340043722C2CA925CCB5A0; Mon Mar 19 21:19:59 2001
>Received: from gecko.ubiquity.net by drago1.ubiquity.net          via smtpd 
>(for [64.4.55.7]) with SMTP; 20 Mar 2001 05:19:42 UT
>Received: from dragon.ubiquity.net by ubiquity.net with SMTP 
>(8.8.8+Sun/25-eef)id FAA01018; Tue, 20 Mar 2001 05:19:39 GMT
>Received: from redball.dynamicsoft.com ([216.173.40.51]) by 
>dragon.ubiquity.net          via smtpd (for gecko.ubiquity.net 
>[193.195.52.22]) with SMTP; 20 Mar 2001 05:19:40 UT
>Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])by 
>redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id 
>AAA16238;Tue, 20 Mar 2001 00:22:58 -0500 (EST)
>Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service 
>(5.5.2650.21)id <FMX9QZ06>; Tue, 20 Mar 2001 00:21:40 -0500
>From [email-masked] Mon Mar 19 21:20:42 2001
>Message-ID: 
><[email-masked]>
>X-Mailer: Internet Mail Service (5.5.2650.21)
>
>
>
>
>
I envisaged this as a solution to the case where the subscriber has been 
rejected with the policy document but the presentity doesn't want them to 
know that. When the subscription is awaiting authorisation the subscription 
will have to be stored as you point out.

James Undery

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2001 11:10:45 -0500

> From: James Undery [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 9:32 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Simple] DoS from rejected subscriptions (was 
> Replacing the
> Q AUTH concept)
> 
> 
> 
> 
> 
> >I'm not following you. What has contacts in the SUBSCRIBE 
> got to do with 
> >it?
> know that.

What is "this" in your sentence above? My question still remains on what you
mean by "contacts in the SUBSCRIBE"?

-Jonathan R.
---

---

From: "James Undery" <[email-masked]>
Date: Wed, 21 Mar 2001 17:14:55 -0000

>To: "[email-masked]'" <[email-masked]>,        Jonathan 
>Rosenberg  <[email-masked]>

>mean by "contacts in the SUBSCRIBE"?

When a SUBSCRIBE is sent to a Presence Server (PS) it contains Contact 
headers, where the NOTIFYs will be sent. I believe (but have been unable to 
confirm in the 01 draft yet) That a 2xx response should contain a list of 
Contact headers relevent to the subscription, this is fine for 200s as the 
user has been authenticated and authorised, however, for 202 that might have 
been rejected as unauthorised, you don't want to maintain enough state to 
return all the Contact headers that they believe should be attached to the 
subscription (based on To, From and Call-ID). It may be better to mandate 
that 202 responses only contain Contact headers present in the SUBSCRIBE 
that generated the response. This allows a PS which knows this subscription 
is rejected as unauthorised to respond without storing state about the 
Contact headers the rejected subscription may have previously supplied. 
Where the status of the subscription's authorisation is unknown the Contact 
headers will have to be stored, but DoS from rejected subscriptions will be 
prevented without leaking presence info.

I realise this might not make sense as I haven't really expanded my thinking 
of how a presence authorisation policy processing language might look, but I 
hope it helps.

James Undery

---

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Mar 2001 13:22:52 -0500

Actually, with -01 we're tracking sip-events, so the subscribe
provides only one contact to be notified, and the final
response contains the contact of the responding UAS (like
INVITE), so that record-route can work.

RjS

> Sent: Wednesday, March 21, 2001 11:15 AM
> >What is "this" in your sentence above? My question still 
> remains on what 
> >you

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

---

From: "James Undery" <[email-masked]>
Date: Wed, 21 Mar 2001 20:49:00 -0000

>INVITE), so that record-route can work.

This would account for the lack of info I found, the sip-events draft is a 
little confused about contacts and the relationship of SUBSCRIBE to 
REGISTER. i.e. it requires a Contact Header in 1xx responses and claims a 
similarity to REGISTER in at least two places where it differs!

In this case DoS by flooding the PS with state isn't a worry as my 
suggestion still stands for all rejected subscriptions where authorisation 
has been refused, without the presentity wishing this disclosed.

Is it sensible to suggest that 2xx responses to a SUBSCRIBE don't contain 
either a Record-Route or a contact and both these elements be potentially 
present only in the accompanying NOTIFY which solves some forking issues 
with RR. (I think, Record-Route isn't my strength and Jo isn't here to help, 
but any partially constructed Record-Route could be placed and used in the 
NOTIFYs I assume or else Adam's previous suggestion for the RR problem 
wouldn't work)

James Undery

---

From: "Adam Roach (EUS)" <[email-masked]>
Date: Wed, 21 Mar 2001 17:20:58 -0600

Thanks. I'll try to find the inconsistencies you cite (although
section numbers on your part would help considerably) and clean
them up for the next release.

The confusion stems from the fact that -00 actually *did* allow
multiple contacts (like REGISTER), but we later decided to take
that behavour out (for a variety of reasons). We'll probably leave
the "Contact" and "Record-Route" behaviour in the SUBSCRIBE
responses just for the purpose of generality (fewer exceptions =
simpler code), although the route will (in some forking cases) be
derived from the NOTIFY response.

/a

> Sent: Wednesday, March 21, 2001 2:49 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2001 21:44:48 -0500

-----Original Message-----
>Sent: Wednesday, March 21, 2001 6:21 PM
>To: [email-masked]; [email-masked]; [email-masked]
AUTH concept)
>derived from the NOTIFY response. 

We haven't agreed to that one yet. At the moment, SUBSCRIBE has INVITE
semantics in terms of Contact, REcord-Route and Route processing, and thats
it. 

I still remain hesitant about getting notifications from multiple
independent devices. I think the complexity will lie in the reconstitution
of a single presence document from the notifications. It also reintroduces
the annoyance of parallel forking, that you can never know when you are
finished getting 200 OK. Here, I may keep getting notifies for additional
new call legs. Its kind of nice that once the 200 OK to subscribe comes, I
know the one and only place notifies will come from.

Might be useful to discuss this tomorrow.

-Jonathan R.

---

---

From: "Adam Roach (EUS)" <[email-masked]>
Date: Tue, 27 Mar 2001 12:16:35 -0600

> semantics in terms of Contact, REcord-Route and Route 

Sorry; I didn't mean to imply that we had formed a consensus on this
topic yet.
 
> know the one and only place notifies will come from.

I think you made a telling slip in your phrasing there:
"reconstitution of a single **PRESENCE** document." In the
general case, SUB/NOT is about more than presence. (Yes, I
know that we're on the SIMPLE list, but the question seemed
aimes at general SUB/NOT behaviour). I encourage SIP presence
to define nominal behavior as rejecting all but the single
"winning" notification.

However, if I am just querying for something simple like
terminal free/busy state, a merge isn't that difficult --
and makes buckets of sense. The same holds for a large set
of interesting states which may be described in event
packages. So, as a base, I beleive SUB/NOT should allow
this sort of structure, so that event packages can use
it if it makes sense. When it doesn't, like in presence,
the event packages may discourage or forbid it.

/a