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
[EMAIL PROTECTED] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
