Technical problem -- correlating dialogs

[Dale.Worley]

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

[Paul Kyzivat]

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

Dale.Worley@... wrote:

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

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

[Huelsemann, Martin-2]

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: bliss-bounces@... [mailto:bliss-bounces@...]
> Im Auftrag von Paul Kyzivat
> Gesendet: Mittwoch, 9. April 2008 23:35
> An: Dale.Worley@...
> Cc: bliss@...
> Betreff: Re: [BLISS] Technical problem -- correlating dialogs
>
> 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
>
> Dale.Worley@... wrote:
> > 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
> > BLISS@...
> > https://www.ietf.org/mailman/listinfo/bliss
> >
> _______________________________________________
> BLISS mailing list
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
>

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

[Paul Kyzivat]

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.
>
> 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

> BR, Martin
>
>
>
>
>
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: bliss-bounces@... [mailto:bliss-bounces@...]
>> Im Auftrag von Paul Kyzivat
>> Gesendet: Mittwoch, 9. April 2008 23:35
>> An: Dale.Worley@...
>> Cc: bliss@...
>> Betreff: Re: [BLISS] Technical problem -- correlating dialogs
>>
>> 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
>>
>> Dale.Worley@... wrote:
>>> 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
>>> BLISS@...
>>> https://www.ietf.org/mailman/listinfo/bliss
>>>
>> _______________________________________________
>> BLISS mailing list
>> BLISS@...
>> https://www.ietf.org/mailman/listinfo/bliss
>>
>

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

[Huelsemann, Martin-2]

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

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:pkyzivat@...]
> Gesendet: Donnerstag, 10. April 2008 16:11
> An: Hülsemann, Martin
> Cc: Dale.Worley@...; bliss@...; Alexeitsev, Denis
> Betreff: Re: AW: [BLISS] Technical problem -- correlating dialogs
>
>
>
> 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.
> >
> > 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
>
> > BR, Martin
> >
> >
> >
> >
> >
> >
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: bliss-bounces@... [mailto:bliss-bounces@...]
> >> Im Auftrag von Paul Kyzivat
> >> Gesendet: Mittwoch, 9. April 2008 23:35
> >> An: Dale.Worley@...
> >> Cc: bliss@...
> >> Betreff: Re: [BLISS] Technical problem -- correlating dialogs
> >>
> >> 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
> >>
> >> Dale.Worley@... wrote:
> >>> 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
> >>> BLISS@...
> >>> https://www.ietf.org/mailman/listinfo/bliss
> >>>
> >> _______________________________________________
> >> BLISS mailing list
> >> BLISS@...
> >> https://www.ietf.org/mailman/listinfo/bliss
> >>
> >
>

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

[Dale.Worley]

   From: Paul Kyzivat <pkyzivat@...>

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

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 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.

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
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

[Paul Kyzivat]

Dale.Worley@... wrote:

>    From: Paul Kyzivat <pkyzivat@...>
>
>    IIUC, the identification is mostly just for authorization, to prevent
>    fraud - getting preferential treatment.
>
> 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.

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

>    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.
>
> 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
> _______________________________________________
> BLISS mailing list
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
>

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

[Huelsemann, Martin-2]

> -----Ursprüngliche Nachricht-----
> Von: bliss-bounces@... [mailto:bliss-bounces@...]
> Im Auftrag von Paul Kyzivat
> Gesendet: Freitag, 11. April 2008 17:39
> An: Dale.Worley@...
> Cc: bliss@...
> Betreff: Re: [BLISS] Technical problem -- correlating dialogs
>
> 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

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



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

[Elwell, John]

 

> -----Original Message-----
> From: bliss-bounces@... [mailto:bliss-bounces@...]
> On Behalf Of Huelsemann, Martin
> Sent: 18 April 2008 11:16
> To: pkyzivat@...; Dale.Worley@...
> Cc: bliss@...
> Subject: Re: [BLISS] Technical problem -- correlating dialogs
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: bliss-bounces@... [mailto:bliss-bounces@...]
> > Im Auftrag von Paul Kyzivat
> > Gesendet: Freitag, 11. April 2008 17:39
> > An: Dale.Worley@...
> > Cc: bliss@...
> > Betreff: Re: [BLISS] Technical problem -- correlating dialogs
> >
> > 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
>
>
> 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-co
> mpletion%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-com
> pletion%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

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

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

[Huelsemann, Martin-2]

> >
> >     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-co
> > mpletion%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-com
> > pletion%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
> [JRE] I don't understand how you get two Call-Info header fields.
>
> John
>

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

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

[Dale.Worley]

   From: Paul Kyzivat <pkyzivat@...>

   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.

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

   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.

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.

   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.

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
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss