Subject: [BLISS] Correlating dialogs, recap

From: [email-masked]
Date: Wed, 23 Apr 2008 22:38:29 -0400

Let me recap the problem that we are seeing in the CC working group,
and then show how the recent discussion affects that.

The problem is the contradiction between three requirements, or
problems:

    1. Privacy Problem:  We desire to prevent a callee's availability
    status from being monitored except as part of a bona fide
    call-completion attempt consequent to an original call from the caller
    to the callee.  To do this reliably requires that the CC subscription
    and CC recall present a non-guessable datum that was present in the
    original call attempt (either request or response).

    2. Call Identification Problem:  All data that are in the original
    INVITE as sent by the caller fall into two classes:  (a) data
    about the caller and callee (that can be guessed), and (b) random
    data (which intermediate middle-boxes feel free to change).  For
    efficiency's sake, we do not want to add a new datum to each
    original INVITE.

    3. Cookie Problem:  All data that are in response(s) to the
    original INVITE are (a) not guaranteed to reach the caller (unless
    we solve some form of the HERFP problem), and (b) in any case,
    cannot be remembered between the original call and the CC
    subscribe by a substantial class of gateways that form a principal
    use case (constellations of SS7-to-SIP gateways).

Paul's suggestion is to weaken the Privacy requirement by allowing the
monitor a choice of a wider range of behaviors.  The reasoning behind
this is that the monitor is a delegate of the callee, whose privacy we
are attempting to protect.  The monitor can combine stricter or looser
rules for authorizing CC subscribes/recalls with hueristics to detect
abuses.  In particular:

In any case, the monitor would authorize subscribes/recalls that
presented a cookie that was embedded in the monitor's URI that was
returned in the response to the original INVITE.

In the absence of the cookie, the monitor would require that the From
and To URIs were the same as those of an original call, and might add
other tests (e.g., whitelisting or originating-address tests) or
activate additional hueristics (to detect abuses).

(The From and To URIs might be modified by intermediate middle-boxes,
but they are likely to be modified in the same way in all three
requests.)

This approach weakens the Privay requirement, eliminates the need for
Call Identification, and circumvents the Cookie Problem.

For further investigation:

There are two principal reasons why a cookie cannot be presented in CC
subscribe/recall:

- The failure response does not reach the caller.  This is most likely
  to happen in complex ("Internet-like") forking structures.

- The caller's agent is memory-less.  This is most likely to happen in
  SS7-to-SIP gateways, but might happen in other high-volume gateway
  situations.

If we can ensure that reliable provisional responses work, we could
use a reliable provisional response to carry the monitor's URI/cookie
back to the agent, which would eliminate the first case.  And in the
second case, the callee might be able to maintain a small whitelist of
gateway addresses.  If both of these can be done, we could
considerably tighten the monitor's authorization hueristics.

Dale
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: [email-masked]
Date: Wed, 23 Apr 2008 22:45:24 -0400

From: [email-masked]

   abuses.

I believe that other members of the CC working group have been
considering the possibility of making the monitor's authorization
policy at its option, rather than being tightly prescribed.  With this
recap, I now start to see what they are considering.

However, the previous formulation had the advantage that it clearly
gave us the behaviors we want (but it couldn't be reliably deployed in
the real world).  The new formulation is heuristic, and we need to do
some more work to ensure that monitor policies can be devised that
satisfy the users' requirements in practical deployments.

Dale