Re: [Simple] Other proposal from View Sharing and Common Notify to reduce presence traffic

[Paul Kyzivat <[e-mail]>]

Do you *really* want to trust other domains to enforce your security 
policies???

I don't. At least not in general. (Maybe there are *some* other domains 
I would trust to do so.)

	Thanks,
	Paul

Victoria Beltrán Martínez wrote:
> Hi,
> 
> Certainly I considered a mechanism to exchange the policy documents of 
> watched presentities between watching and watched domains in Common 
> Subscribe solution. The watching domain (RLS) subscribes to an event 
> (called “privacy filters”) in presentity domain’s presence server. 
> Whenever a change in the policy documents for any of the presentity’s 
> watchers happens, a NOTIFY message with “event=privacy filters” is sent 
> from presentity’s presence server to watchers’ domain. The watching RLS 
> maintains one subscription to “privacy filters” event per watched 
> presentity. This subscription could be explicit if existing watchers 
> were indicated into the body of SUBSCRIBE messages. In this way, when a 
> new watcher is added a re-SUBSCRIBE message containing the updated 
> watcher list is sent and a NOTIFY message with the policy documents will 
> be received by the RLS in response to this resubscription. However, a 
> privacy filters subscription could be implicit so that the watcher list 
> is not needed in SUBSCRIBE messages, a simple SUBSCRIBE creates a 
> subscription to all the existing watchers of the watched presentity. 
> Clearly, a trust relationship between watching RLS and watched PS is 
> needed to share full-state presence and policy documents of watched 
> presentities.
> 
> When the watching domain subscribes to a presentity, the SUBSCRIBE 
> message contains the list of existing watchers in order to let the 
> watched domain know what watchers are watching the presentity. The OK 
> response from the watched domain includes the list of authorized 
> watchers to see some view of the presentity’s presence. A view of 
> presence is defined by a policy document.
> 
> Assuming N watched presentities , with Common Subscribe the watching RLS 
> will maintain 2*N subscriptions (N for presence event and N for privacy 
> filters event). In case of View Sharing, the RLS will maintain N*F 
> setting F as the number of different policy documents per presentity. At 
> first sight, we can imagine how the performance of VS gets worse as F 
> increases.
> 
> In addition, the fact that policy documents change rarely allows us one 
> interesting possibility with Common Subscribe. When a common 
> subscription is created for a presentity in the watched domain’s 
> Presence Server, automatically a “logical” subscription to the policy 
> documents associated to the presentity is created too. In this way, the 
> watching domain receives two initial NOTIFY messages (or a single 
> multipart NOTIFY), one contains the presentity’s presence and another 
> one contains the policy documents. Once the policy documents are 
> downloaded is more than likely that privacy rules don’t change during 
> the session, so that we save unnecessary signaling traffic to keep alive 
> subscriptions to privacy filters events. Anyway, if a change of privacy 
> rules associated to a presentity happened it would be notified as a 
> NOTIFY message into the common subscription between the presentity and 
> the affected watchers’ domain. Now, if there are N presentities, the 
> total number of subscriptions maintained by the watching RLS is N. I 
> have called this mechanism as internal privacy filters subscription.
> 
> I did several assumptions to estimate the performance of Common 
> Subscribe and View Sharing. I supposed the presence federation scenarios 
> described in section 2.8 of the draft “Presence Interdomain Scaling 
> Analysis for SIP/SIMPLE”) (ietf-simple-interdomain-scaling-analysis-04). 
> I considered both implicit and internal privacy filters subscriptions 
> when Common Subscribe was applied. With View Sharing, I agree with David 
> that filter-based subscriptions are subject to less frequent change, so 
> I supposed that each change affected half of the privacy filters on 
> average (a notification was generated in half of the existing 
> filter-based subscriptions on average). The number of filter-based 
> subscriptions between watching and watched domains is equal to the 
> number of different policy documents associated to watchers in the 
> watching domain. I considered several numbers of policy documents 
> depending on the number of watchers per presentity. My calculations show 
> that Common Subscribe is more scalable than View Sharing and it achieves 
> around 50% improvement of presence traffic in the majority of cases.
> 
> Regards,
> 
> Victoria
> 
> 
> En/na David Viamonte ha escrit:
>> Hi,
>>
>> I agree with Sanjay that, at first sight, it seems that for this 
>> alternate proposal to work, a sharing of (part?) of the Presence 
>> authorization policies between serving and watching domains is needed. 
>> On the other hand, making a single "domain-to-domain" subscription as 
>> Victoria suggests would be the simplest and probably most simple 
>> mechanism to distribute Presence information across domains. In such 
>> case the watching domain (RLS) would have responsibility of 
>> implementing Presence policies about Presentities in remote domains.
>>
>> In practice, the need for sharing policy documents is implicitly 
>> mentioned in the "Security Considerations" section of 
>> "draft-ietf-sipping-presence-scaling-requirements-01". According to 
>> that section, no decision has been made yet about allowing or 
>> discouraging such approach (delegating privacy protection from one 
>> domain to the other). On the contrary, it seems to be left FFS to 
>> decide whether this is an acceptable security risk or not ("important 
>> part of work on the requirements and optimizations will be to make 
>> sure that all the security aspects are covered").
>>
>> Furthermore, my understanding is that, in practice, this 
>> "domain-to-domain single subscription" mechanism does not require the 
>> complete Presence or Policy documents being exchanged, only those that 
>> might be applicable to any user in the watching domain (of course, 
>> including a mechanism to update policies, if needed). In fact, I think 
>> EXACTLY the same comments in the Security Considerations section of 
>> the View Sharing draft ("if it generated a subscription from each of 
>> its subscribers it would be able to determine who from its domain is 
>> allowed to subscribe and what view they would receive") are applicable 
>> to Victoria's proposal, so I fail to see substantial security 
>> differences between both approaches. I could envisage potential 
>> "logistic" issues, though...
>>
>> Since I am not a security expert, my conclusion is that getting an 
>> understanding on whether there are fundamental diferences (from the 
>> security perspective) between both approaches would be very valuable. 
>> In case there are not such differences, the proposed alternative looks 
>> interesting, as it seems to represent a very important simplification 
>> (in practice, there would be no need to define any SIP extension at 
>> all). It is fair to say that a mechanism to exchange policies would 
>> need to be defined (not sure is that is covered elsewhere?).
>>
>> When it comes to traffic reduction, my understanding is that the 
>> "common subscription" mechanism "should" be more efficient than the 
>> view sharing approach. Even though it leads to larger documents being 
>> exchanged (thus containing more Presence information, which is subject 
>> to more frequent change), such documents are delivered only once per 
>> domain, while in the view sharing case documents are delivered to each 
>> list of watchers sharing a same "policy profile". This is only a 
>> preliminary comment without having made serious calculations :-)
>>
>> Just my 2 cents,
>>
>> David
>>
>>
>>
>>
>> Sanjay Sinha (sanjsinh) escribió:
>>> What about allowed/blocked list that a presentity may have, if there 
>>> is a single subscription between watcher domain's presence server and 
>>> the watcher presentity.
>>>
>>>
>>>
>>>  
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>> Behalf Of Victoria Beltrán Martínez
>>>> Sent: Wednesday, October 15, 2008 1:11 PM
>>>> To: [e-mail]
>>>> Subject: [Simple] Other proposal from View Sharing and Common Notify 
>>>> to reduce presence traffic
>>>>
>>>> Hi,
>>>>
>>>> The Common Notify technique (described in the expired draft "Scaling 
>>>> Optimizations for Presence in SIP/SIMPLE,
>>>> houri-simple-interdomain-scaling-optimizations-00) is intended for 
>>>> reducing presence traffic between federated domains. Other draft, 
>>>> "Optimizing Federated Presence with View Sharing" 
>>>> (ietf-simple-view-sharing-01) has the same intention. From these 
>>>> proposals,  I was thinking the idea of a single subscription between 
>>>> watcher and watched domains, so that the presence server in the 
>>>> watcher domain is in charge of subscribing to the watched 
>>>> presentity.  Then, the presence server mantains the list of watchers 
>>>> that are watching each presentity and this list hasn't to be sent in 
>>>> NOTIFY messages. In this way, we avoid the increase of signaling 
>>>> traffic as the number of watchers grows in the case of Common Notify 
>>>> and as the number of privacy filters grows in the case of View Sharing.
>>>>
>>>> Have anyone considered this solution? I have read nothing about it.
>>>>
>>>> I named this solution as Common Subscribe and compared it with 
>>>> Common Notify and View Sharing. I did several assumptions based on 
>>>> IETF drafts and I proved that Common Subscribe reduces around  50% 
>>>> of presence traffic generated by View Sharing and Common Notify.
>>>>
>>>> thanks,
>>>> Victoria
>>>> _______________________________________________
>>>> Simple mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>
>>>>     
>>> _______________________________________________
>>> Simple mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/simple
>>>   
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus 
>>> Database: 270.8.1/1728 - Release Date: 16/10/2008 7:38
>>>
>>>   
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this outgoing message.
>> Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 
>> 270.8.1/1728 - Release Date: 16/10/2008 7:38
>>
>>   
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple