Subject: [Simple] Comments on draft-ietf-simple-event-list-02

From: [email-masked]
Date: Fri, 09 May 2003 09:28:12 -0400

Adam et all

I have some comments regarding draft-ietf-simple-event-list-02.

First issue is whether consideration has been given to the possibility of loops being set up by lists containing other lists that ultimately reference back to the original list either unintentionally or as a malicious attack. This would seem to be a particular problem if the lists are in different domains with the potential for subscribe requests to be continually generated. Different domains also makes these loops impossible to detect at list creation time.

For example three lists are created; A, B and C all in different domains with B having A as a member. A is then modified to also contain C and C is also modified to contain B as a member:

W----->C(B)----->B(A)----->A(C)--
        ^                        |
        |                        |
        -------------------------

If I understand the RLS subscription procedure correctly a watcher (W) subscription to C causes C to send a SUBSCRIBE request to B which causes B to send a SUBSCRIBE request to A since B should not cache the state of subscriptions to A for different watchers (7.2 Risks of Improper Aggregation) as the authorization policy and presence data returned for each watcher may be different. Doesn’t this in turn cause A to send a SUBSCRIBE request to C causing C to send a SUBSCRIBE request to B and so on in a loop?

It seems that C needs to be able to detect that the SUBSCRIBE from A is related to the original SUBSCRIBE from watcher W and hence not generate a new SUBSCRIBE to B and probably reject the subscription from A.

Currently I don’t see anything in the current document or in the Subscribe request from an RLS that identifies the original watcher or the original subscribe; which it seems would be needed to prevent such loops from occurring.

Is this a genuine problem or am I misunderstanding something about the mechanism?

If it is a problem then it seems we need some discussion on this and a solution. One possibility might be to include a SIP Frag containing the dialog of the original watcher subscription in SUBSCRIBE requests from the RLS and have the RLS check each SUBSCRIBE to see if it has an existing identical dialog.

Second comment is that IMHO the text in 5.4 Instance Attributes does not seem to indicate what is shown in the example regarding the use of the Instance Attribute in the first full state Notify that is returned by an RLS before the results have been received for the resource that is in another domain. The text in 5.4:

“Each resource element contains one or more instance elements.  These
   instance elements are used to represent a single notifier for the
   resource.  For event packages that allow forking, multiple virtual
   subscriptions may exist for a given resource.  Multiple virtual
   subscriptions are represented as multiple instance elements in the
   corresponding resource element.  For subscriptions in which forking
   does not occur, at most one instance will be present for a given
   resource.”

My interpretation of this text is that the one or more indicates that an instance element should always be present for each resource element. However the example shows that this is not the case in the Notify in step 3 (No instance element for resource [email-masked]). IMHO some clarification is necessary here.

regards
Andrew

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 12 May 2003 13:53:25 -0500

Andrew Allen writes:

> Currently I don’t see anything in the current document or in 
> the Subscribe request from an RLS that identifies the 
> original watcher or the original subscribe; which it seems 
> would be needed to prevent such loops from occurring.
> 
> If it is a problem then it seems we need some discussion on 
> this and a solution. One possibility might be to include a 
> SIP Frag containing the dialog of the original watcher 
> subscription in SUBSCRIBE requests from the RLS and have the 
> RLS check each SUBSCRIBE to see if it has an existing 
> identical dialog.

This document explicitly points out in several places that
the back-end subscriptions may or may not be SIP. We can't
put a SIP-specific mechanism in place to address them.

The issue of infinite recursion does deserve a mention in
the document, and will be added to the security section.

Solutions for the general case will be left to implementors.

Solutions for the case in which SIP is used on the
back end will be described in the forthcoming informative
document that discusses implementation of event list
servers with SIP back-end subscriptions.
 
> Second comment is that IMHO the text in 5.4 Instance 
> Attributes does not seem to indicate what is shown in the 
> example regarding the use of the Instance Attribute in the 
> first full state Notify that is returned by an RLS before the 
> results have been received for the resource that is in 
> another domain. The text in 5.4:
> 
> "Each resource element contains one or more instance elements.  These
>    resource."
> My interpretation of this text is that the one or more 
> indicates that an instance element should always be present 
> for each resource element. However the example shows that 
> this is not the case in the Notify in step 3 (No instance 
> element for resource [email-masked]). IMHO some clarification 
> is necessary here.

You are correct. The introductory sentence in that paragraph
should say "zero or more", not "one or more". Thanks for
catching the inconsistency.

/a