Subject: RE: [Simple] WGLC: partial notification

From: [email-masked]
Date: Thu, 29 Apr 2004 15:44:25 +0300

> -----Original Message-----
> From: Lonnfors Mikko (Nokia-NRC/Helsinki) 
> Sent: 29.April.2004 15:40
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> Subject: RE: [Simple] WGLC: partial notification
> 
> 
> 
> <snip>
> 
> > > > Ok, so your proposal is that "version" should be scoped with
> > > > the subscription i.e. first NOTIFY within a subscription 
> > > > would have version="0" and then it would be continuously 
> > > > increased by one for every notifications (regardless if it 
> > > > contains full or partial state)?
> > > > 
> > > > How should subscription refreshes be handled? If we have
> > > > PA sends N1(full), N2(full), N3(partial)
> > > > And N2 is lost watcher would refresh the subscription when it
> > > > receives N3. Now
> > > > Would the PA send N1(full, version="0") or N4(full, 
> version="3")?
> > > 
> > > version gets reset to 0 when a SUBSCRIBE refresh is received.
> > 
> > Now that I think about this a little more, I think the 
> > version should forever increase for the whole duration of the 
> > subscription, including refreshes. Imagine this scenario:
> > 
> > ----> SUBSCRIBE
> > <---- 200
> > <---- NOTIFY1 (full, version 0)
> > ----> 200
> >   X-- NOTIFY2 (full, version 1)
> > <---- NOTIFY3 (partial, version 3)
> > ----> 200
> > ----> SUBSCRIBE
> > <---- 200
> > <---- NOTIFY4 (full, version 0)
> > ----> 200
> > <--x  NOTIFY2 (full, version 1) Now NOTIFY2 arrives
> > 
> > How does the subscribe know that the last NOTIFY (NOTIFY2) 
> > was sent after the subscribe refresh? If NOTIFY 4 had version 
> > 4 instead of 0, then it would.
> > 
> > /Hisham
> 
> If we don't allow new NOTIFY messages if there is a pending 
> NOTIFY is this still a problem?

This would fix the problem, but I prefer not to disallow it since
RFC3265 does not disallow it nor presence-07.

I believe increasing the version for the duration of the subscription
would fix this.

/Hisham

> - Mikko

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 08:43:06 -0500

inline
> I believe increasing the version for the duration of the subscription

See my response to Paul's variation of this suggestion.
If you do this, you open a new attack against this mechanism.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 08:46:43 -0500

> RFC3265 does not disallow it nor presence-07.

It's still an open question whether leaving the possibility of
overlapping NOTIFYs in a subscription was a good idea. In this
case, we've identified a place where it isn't, and where disallowing
them is a simpler solution than putting in the machinery to deal
with them ->for no gain in functionality<-.

So, I don't understand your sentiment.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 08:43:06 -0500

inline

RjS

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 08:46:43 -0500

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2004 11:42:05 -0400

> If you do this, you open a new attack against this mechanism.

If someone is in a position to mount that kind of attack, how do any of 
these approaches improve the attackee's experience?

Apparently the attacker can inject arbitrary bogus notifications at any 
time. If the recipient can "recover" when it receives a notification 
with good data, then it will have no way of knowing when it has good 
data and when it has bad data. How is that better than having the attack 
crash the subscription altogether? At least then it will know it is 
under attack.

The only real defense here is a secure session.

	Paul

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2004 11:42:05 -0400

Paul

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 12:44:53 -0500

Of course a secure session is the correct defense.

Understanding the differences in the behavior of the proposed
changes without that security is still a useful tool for
comparing them. Those differences may have ramifications in
scenarios other than the attack/security scenario I'm using
to point at them.

The current draft (almost) has the property that a client
can reset all the partial-oriented state by issuing a 
subscription refresh. It can get back to a clean start-state
wrt the extensions being defined here.

If you change to increasing versions across full notifications,
a client has to tear down the subscription and resubscribe to
get back to that clean start-state.

I think we want to preserve (and refine) the property the current
draft has.

RjS

---

From: David Oran <[email-masked]>
Date: Thu, 29 Apr 2004 13:47:36 -0400

from left field...could this be solved by using the CSEQ of the 
subscription refreshes as the high order part of the version number?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2004 14:01:46 -0400

> wrt the extensions being defined here.

This only comes up if somebody malicious is (successfully) hacking into 
the session. The client can attempt to reset, but can be hacked again 
after that. There is no reason for the client to assume that any results 
it gets are valid once it has been hacked. Nor does it know that it has 
been hacked. From the client's pov this is at least as likely to be 
assumed to be a malfunction of the server.

> I think we want to preserve (and refine) the property the current

Even tearing down the subscription and establishing a new one isn't 
likely to be helpful if you have an active attacker. If the hacker got 
in once, he can probably get in again. But if that is hard to do, then 
establishing a new session may give slightly better results.

This is probably when you call for help to find and block the hacker. 
You may just have to give up on the subscription until then.

I don't find any *useful* differences in resilience of the various 
alternatives to this kind of attack.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 13:20:37 -0500

Aside from that I'd like for you to think through this again
from viewpoints besides active attack (use a transient malfunction
of the application (above the layer that would screw up basic SIP)),
I'm ready to let this go as long as we have _a_ solid solution to
dealing with reordered/missing notifies.

So, backing out a layer, lets look at my original question of
whether or not we allow overlapping ->partial<- NOTIFYs at all
in this case.

Why would you want to? What value would doing that bring? 

3261 and even presence-10 left sending full-state presence
NOTIFYs open. We wouldn't be changing that. If an application
for some reason decided it needed to send a new full-state
notify while a partial-state notify was pending, it could.
So any of the arguments for allowing it from the 3261/presence-10
are still satisfied. Can you see any use case where allowing
a server to send overlapping partial NOTIFYs is a good idea?
If not, disallowing it seems a powerful simplification.

RjS

---

From: Ben Campbell <[email-masked]>
Date: Thu, 29 Apr 2004 13:28:36 -0500

> crash the subscription altogether? At least then it will know it is 

Part of this depends on how much effort the attacker must go to. If 
version numbers increase forever for the life of the subscription, then 
a _single_ spoofed notify  with a very high version causes a train 
wreck. There is no way to recover, short of tearing down the 
subscription and starting over.

If, on the other hand, we reset the version to zero on a subscription 
refresh, then when the watcher notices an out-of-sequence NOTIFY, it 
refreshes the subscription, and re-syncs. Of course, if this forces a 
full state notify, it is not much cheaper than a new subscription, so 
maybe it is not worth the trouble.

In either case, an attacker that _continues_ to attack will pretty much 
make the subscription useless.

> The only real defense here is a secure session.

That would certainly help, although if you mean TLS lever security, then 
a compromised proxy could still attack. (And who else is in a better 
position to know enough dialog state to pull this off, anyway?) And I 
know the sort of welcome that suggesting that the notifier s/mime sign 
everything would get.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2004 14:46:38 -0400

> dealing with reordered/missing notifies.

I'm not going to start down the path to speculation about how to recover 
from arbitrary malfunctions of an application. That is just plain 
impossible without some characterization of the kinds of malfunctions 
that are to be recovered from.

> whether or not we allow overlapping ->partial<- NOTIFYs at all

I don't see any compelling need to support overlapping partial notifies. 
It is very difficult to see how to make them work.

I can imagine a case where there might be some motivation: I sent one 
notification and have had no response. But I already have a bunch of 
additional changes that you should know about. It might be advantageous 
to start sending them as soon as possible. But until you know the prior 
one has been handled it isn't safe to send the new one.

> If not, disallowing it seems a powerful simplification.

I agree.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 12:44:53 -0500

RjS

---

From: David Oran <[email-masked]>
Date: Thu, 29 Apr 2004 13:47:36 -0400

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2004 14:01:46 -0400

Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 13:20:37 -0500

RjS

---

From: Ben Campbell <[email-masked]>
Date: Thu, 29 Apr 2004 13:28:36 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2004 14:46:38 -0400

I agree.

	Paul