Subject: [BLISS] Technical problem -- correlating dialogs

From: [email-masked]
Date: Wed, 9 Apr 2008 12:14:42 -0400

This is a problem that we've been discussing on the Call Completion
mailing list and we would like to put it in front of the entire Bliss
mailing list for people to suggest solutions.

The problem runs:

(To simplify,) once an initial caller has made a call to a UAS that
has failed, the caller sends a SUBSCRIBE ("the CC subscribe") to a
particular UAS to state its desire to make a CC call, and to receive
notice of when it should make its CC re-call.  (Currently, the
expectation is that the CC subscribe will be made to the same URI as
the original call.  It might be possible to change that, but that
turns out to involve the same technical problem described below.)

Because a CC subscribe displays busy/not-busy information about the
callee without itself making an INVITE to the callee, in order to
protect privacy, we don't want to allow UAs to arbitrarily perform CC
subscribes -- they have to present identification of a previous call
that they have made to that destination, thus ensuring that the callee
is aware of the caller's interest.

Some UAC callees are nearly memory-less.  (In particular, constellations
of gateways that bridge from SS7 networks to SIP networks.)  Thus, the
only information that can be carried reliably from the destination of
the (failed) original call to the CC subscription and the CC recall is
the "mode" (CCBS vs. CCNR), because that is carried back into the SS7
network and is carried forward in the SS7 CC operations.

This means that the "identification" that we require of the CC
subscribe must be some aspect of the original call; it cannot be a
datum from the response to the original call (because a memoryless UAC
cannot remember the datum).

This means that any call to which CC can be applied later must bear
some sort of identification which will later be carried in the CC
subscribe and CC recall.  This would be straightforward -- just use
the Call-Id -- except that calls frequently pass through SBCs or
B2BUAs that change the Call-Id.

Let us examine what might be used for identification:

There are two sorts of data that an INVITE carries.  The first sort is
data about the nature of the call (To, From, etc.).  Because it is
relatively easy to guess, this data is not suitable for CC
identification.  The second sort is pseudo-random data used to
identify the call (Call-Id, to-tag, from-tag).  By its very nature,
SBCs feel free to change the second sort of data when passing a call
through, so the UAC and UAS do not necessarily see the same values of
these data.

One alternative is to add a new header with a pseudo-random value, and
expect that SBCs will not change it.  (And hope that SBCs will pass it
through, which is plausible.)  But in order to reduce the burden on
the UASs and the network, we don't want to add an additional CC
identifier to every call that is generated, but it appears that we
have to to get calls reliably identified for CC.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 17:34:46 -0400

Suppose you just authorized subscribers based on a From-URI matching 
that of a recent call attempt? As you note, it would be easy for others 
to guess this, but what bad things happen as a result?

To take advantage of this I must forge your From address (perhaps easy), 
but I must also know that you have made a call attempt that failed.

How is that better than just making my own call attempt in the first 
place, using either my own From, or yours if I am capable of forging it?

I guess it means I can jump ahead of you in line, but only if I was 
monitoring your usage to start with.

I suppose there are *some* cases where that would be valuable, but are 
they important cases?

Another thing you might use is the Contact address, which might be a 
little harder to guess, but not a lot harder normally. And it might be 
bad if you want to make the CC from a different extension.

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 10 Apr 2008 13:03:29 +0200

Can't this be done by 2 different ways? First the normal way with delivering something like a CC identifier back to the CC agent which then ist used druring the subscription and the CC call. The other way would be the fallback for stateless UAs (and gateways) to reassemble the identifier from information available from the original call (first choice information about caller and callee). During design team discussion Dale also introduced a keying mechasim guarateeing privacy settings.

Anyway with this approach the identification would actually only be needed for the subscription and the CC call.

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Paul Kyzivat
> Gesendet: Mittwoch, 9. April 2008 23:35
> An: [email-masked]
> Cc: [email-masked]
> Betreff: Re: [BLISS] Technical problem -- correlating dialogs
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 10:11:07 -0400

> Anyway with this approach the identification would actually only be needed for the subscription and the CC call.

IIUC, the identification is mostly just for authorization, to prevent 
fraud - getting preferential treatment.

If you have two ways, and one of them provides an opportunity for fraud, 
and the other not, then those intent of fraud will use the one that 
supports it. There is then little motivation to implement the other 
method, since it will only be used by those who would do the right thing 
with the weaker mechanism.

What am I missing?

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 11 Apr 2008 03:05:05 +0200

Yes, you are right, probably implementations will only go the easy way. Although something like a shared key between CC agent and CC monitor would it not make too easy for them.

But what I wonder is do we need anyway to specify the identifier in deep? This could also be a policy between agent and monitor? The CC draft could give some guidelines?

What we need of course is a mechanism to transport the identifier. 

BR, Martin

> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Donnerstag, 10. April 2008 16:11
> An: Hülsemann, Martin
> Cc: [email-masked]; [email-masked]; Alexeitsev, Denis
> Betreff: Re: AW: [BLISS] Technical problem -- correlating dialogs
> 
> 
> 
> > Can't this be done by 2 different ways? First the normal 
> way with delivering something like a CC identifier back to 
> the CC agent which then ist used druring the subscription and 
> the CC call. The other way would be the fallback for 
> stateless UAs (and gateways) to reassemble the identifier 
> from information available from the original call (first 
> choice information about caller and callee). During design 
> team discussion Dale also introduced a keying mechasim 
> guarateeing privacy settings.
> > 
> > Anyway with this approach the identification would actually 
> only be needed for the subscription and the CC call.
>

---

From: [email-masked]
Date: Fri, 11 Apr 2008 11:22:28 -0400

From: Paul Kyzivat <[email-masked]>

I don't think that even this mild form of fraud is a problem, as one's
position in the queue is determined by when one makes the
subscription.  My concern is privacy -- having a CC subscription
allows monitoring the alleged callee's presence/availability
information without having placed a call to the callee first.  Given
current telephony usage (caller-ID), users are much more likely to be
aware of someone calling them on a regular basis than someone
continuously subscribed to the CC service.  And given the
near-anonymity of SIP requests, it would be hard to detect
privacy-invasive exploitation of CC subscriptions.

If you replace "fraud" with "invastion of privacy", this is my
concern.

   Huelsemann, Martin wrote:
   Can't this be done by 2 different ways? First the normal way with
   delivering something like a CC identifier back to the CC agent
   which then ist used druring the subscription and the CC call. The
   other way would be the fallback for stateless UAs (and gateways) to
   reassemble the identifier from information available from the
   original call (first choice information about caller and
   callee). During design team discussion Dale also introduced a
   keying mechasim guarateeing privacy settings.

The difficulty with a keying mechanism is that we cannot assume that
the caller's agent and the callee's monitor share a key.  I doubt that
we could implement that in practice even in a walled-garden run by a
bureaucratic service provider.

Once we decide that the key is present only in the caller's agent, we
have a need to transmit the key-derived identifier to the callee's
monitor.  But at that point there is a conflict -- we don't want to
add to every INVITE an additional datum, but at the same time, all the
data in an INVITE seem to be either easily guessable or intermediate
B2BUAs feel free to change them.

Perhaps we need to study more carefully whether this is needed to
prevent abuse of privacy.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Apr 2008 11:39:05 -0400

> privacy-invasive exploitation of CC subscriptions.

Use of the From to validate the subscription prevents casual monitoring 
of callee availability. The subscription would only be authorized if 
there was a call attempt with that From address that is still eligible 
for CC.

Admittedly it isn't very strong. If you can guess somebody who has made 
a call attempt you can bypass this. But it might be strong enough for 
the purpose. How is it worse that making the call attempt and canceling 
the call after the first provisional response? The presence of the 
subscription, with its routing info, allows the callee to identify who 
is watching if they are paranoid about it.

And I suppose this could be combined with some other sort of 
authorization. There could be one mechanism with a cookie for those who 
can support it, and this weaker mechanism could require some special 
credential or a whitelist, that was by policy restricted to gateways.

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 18 Apr 2008 12:15:48 +0200

> Gesendet: Freitag, 11. April 2008 17:39

Hi,

I also think for the internet draft it could be sufficient to concentrate to describe the cookie mechanism for a pure internet environment and strongly recommend to use this, but mention the option for a weaker (but possibly also cookie) mechanism. Possibly also in combination with a whitelist for the subscription. But any way this could be described in specs for networks that can guarantee to prevent invastigation of privacy, which I think will be possible for example in the 3GPP IMS.

The other question is, how is the cookie conveyed from monitor to agent? Did we come to a conclusion for this? Is it possible to use the Call-Info header for this purpose? In the design team there was a discussion to use the Call-Info header in the following way:

    For example, consider this header inserted in a response by a monitor:

    Call-Info: <sip:atlanta.example.com?Call-Info=%3cx:y%3e;purpose%3dcall-completion%3bcookie%3d123456>
	    ;purpose=call-completion
	    ;m=NR

    The contained monitor's contact URI is thus:

    sip:atlanta.example.com?Call-Info=%3cx:y%3e;purpose%3dcall-completion%3bcookie%3d123456

    When that URI is used to generate a SUBSCRIBE, the resulting request
    looks like this:

   SUBSCRIBE sip:atlanta.example.com SIP/2.0
   Call-Info: <x:y>;purpose=call-completion;cookie=123456
   Call-Info: <...>;purpose=call-completion;m=NR

Could this be a way forwar to transport the cookie?

BR, Martin

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Apr 2008 13:53:33 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Huelsemann, Martin
> Sent: 18 April 2008 11:16
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [BLISS] Technical problem -- correlating dialogs
> 
> 
> 
> I also think for the internet draft it could be sufficient to 
> concentrate to describe the cookie mechanism for a pure 
> internet environment and strongly recommend to use this, but 
> mention the option for a weaker (but possibly also cookie) 
> mechanism. Possibly also in combination with a whitelist for 
> the subscription. But any way this could be described in 
> specs for networks that can guarantee to prevent 
> invastigation of privacy, which I think will be possible for 
> example in the 3GPP IMS.
> 
> 
> 
> The other question is, how is the cookie conveyed from 
> monitor to agent? Did we come to a conclusion for this? Is it 
> possible to use the Call-Info header for this purpose? In the 
> design team there was a discussion to use the Call-Info 
> header in the following way:
> 
> 
> 
>     Call-Info: 
> <sip:atlanta.example.com?Call-Info=%3cx:y%3e;purpose%3dcall-co
> mpletion%3bcookie%3d123456>
> 	    ;purpose=call-completion
> 	    ;m=NR
> 
[JRE] I don't understand how you get two Call-Info header fields.

John

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 22 Apr 2008 18:01:08 +0200

> [JRE] I don't understand how you get two Call-Info header fields.
Hi John,

if I renember correctly the explanation was the following:

  The first Call-Info has been inserted by the processing of the
  "?Call-Info" header-parameter in the monitor's contact URI.  The
  second Call-Info has been inserted by ordinary CC SUBSCRIBE generation
  by the caller's agent.  But since the monitor created this situation,
  it knows how to interpret two Call-Info values.

BR, Martin

---

From: [email-masked]
Date: Wed, 23 Apr 2008 14:51:11 -0400

And the From URI is a datum that is already carried end-to-end.

That is true -- the callee's monitor has a considerable amount of
information about the CC subscriber, and can police the subscriptions
for suspicious behavior.  For example, subscriptions that last too
long; subscriptions that when given the go-ahead, do not execute CC
recall; or subscriptions that are always in "unavailable" state.

That's true, too.  The authorization decision is made unilaterally by
the callee's monitor, allowing different monitors to enforce different
policies.  And in many PSTN-to-SIP applications, the set of gateways
that can route a PSTN call to the callee is knowable.

If we incorporate any "cookie" (that is, a identifying datum carried
from the UAS of the original call, to the UAC, to be presented with CC
subscribe or CC recall) as part of the callee's monitor's URI (which
we intend to be utilizing anyway), then the choice between these
authorization mechanisms is entirely in the hands of the callee's
monitor.

Dale