Re: [BLISS] I-D Action:draft-ietf-bliss-call-completion-06.txt

Hi all,
It is also our understanding that we have decided to abandon the correlation, because of the issues Dale mentioned. 
Therefore we agree on Dales proposed changes. We are currently preparing a revision of the draft (-07) and propose to incorporate the changes.

Best Regards

Roland and Martin

-----Ursprüngliche Nachricht-----
Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] Im Auftrag von WORLEY, Dale R (Dale)
Gesendet: Donnerstag, 8. Juli 2010 00:40
An: Scott Lawrence; bliss@ietf.org
Betreff: Re: [BLISS] I-D Action:draft-ietf-bliss-call-completion-06.txt

________________________________________
From: bliss-bounces@ietf.org [bliss-bounces@ietf.org] On Behalf Of Scott Lawrence [xmlscott@gmail.com]

There is an issue in the tracker:

http://trac.tools.ietf.org/wg/bliss/trac/ticket/1

do you believe that the new draft addresses it?
_______________________________________________

The text of that Trac issue is:

> If CC does not enforce correlation with incoming calls, we need to document how implementations should ensure privacy.
>    Section 11 (Security Considerations) needs to be updated to take care of this. The text in -05 still describes CC correlation.

My understanding of the design consensus is that we've decided to abandon any attempt at "call correlation", that is, a SUBSCRIBE to a CC queue is not required to present evidence that the subscriber previously made a failed call to the destination.  We decided this because it is impossible to implement in the presence of SBCs (which are ubiquitous in the PSTN/SIP world), and because the PSTN CC feature does not enforce call correlation either.

As far as we can figure out, even without call completion, it is difficult to adversely affect the destination's privacy without using a pattern of SUBSCRIBEs which is significantly different from ordinary usage.  But we need to provide security guidance about this.

Relative to the -10 draft, I think we need to make the following changes:

Section 9.7, delete this paragraph:
>   If it is not possible to correlate a SUBSCRIBE request with a queue
>   entry then the notifier SHOULD send a 481 Call/Transaction Does Not
>   Exist response.

Section 7.2, modify this paragraph by removing the indicated sentence:
>   The callee's monitor(s) that receive the SUBSCRIBE establish
>   subscriptions.  These subscriptions represent the caller's agent's
>   request for call-completion services.  The callee's monitor MUST be
>   prepared to receive multiple forks of a single SUBSCRIBE, and should
>   respond 482 (Merged Request) to all but one fork.
>   [remove this sentence:]  The callee's
>   monitor MUST be prepared to receive SUBSCRIBEs regarding original
>   calls that it has no knowledge of, and should respond 481 (Call/
>   Transaction Does Not Exist) to such SUBSCRIBEs. [/remove]
>   The monitor may
>   apply additional restrictions as which caller's agents may subscribe.

Section 11 (Security Considerations), change the first paragraph to:
>   The use of the CC facility allows the caller's agent to determine
>   some status information regarding the callee.  The information is
>   confined to a busy/not-busy indication, and in legitimate use, 
>   will be subscribed to stereotyped ways that limit the disclosure of
>   status information:
>
>   (1) When a subscriber is selected for CC, a call should arrive
>   promptly for the callee, or the subscription should be terminated.
>   This expectation may be violated by a race condition between
>   selection of the subscription for CC and the caller becoming
>   unavailable, but it should be rare that a single subscription will
>   exhibit the race more than once.
>
>   (2) Subscriptions should not remain suspended for longer than the
>   expected duration of a call (a call by the caller to a third party).
>
>   (3) Subscriptions should be initiated only shortly after failed
>   incoming calls.
>
>   (4) Most of the time, a callee should have no queued subscriptions.
>
>   Violations of these expectations should be detected by the callee's
>   monitor and reported as possible attempts at privacy violation.

Dale
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss