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 protected]
https://www.ietf.org/mailman/listinfo/bliss
