Re: [Sipping] New Internet Draft for Caller Identity Blocking

[Victor Pascual Ávila <victor.pascual.avila at gmail.com>]

Hi Hadriel,
thanks a lot for your comments. Some comments inline.

On Mon, Mar 2, 2009 at 4:12 PM, Hadriel Kaplan <HKaplan at acmepacket.com> wrote:
> I like the purpose of your draft a lot, to let receiving users block future calls from the same source.  But I'm not sure the implementation of it is quite right.  It seems to me that if I want to block a user from calling me indefinitely, I'd want it to be known by more than the proxy chain sending it to me.  In particular, I'd probably want it to be known to the Registrar or at least some database multiple proxies of my provider can query.  That way if there are multiple proxies which can reach me, or the proxy is rebooted/replaced/whatever, or I move/roam and end up using another proxy, the block-list is not lost.

When the proxy gets the blocking information, it should update the
"shared database" with this information.

>
> Obviously in a 3GPP-specific model you could have the S-CSCF or some other node perform such an update to the HSS or whatever, but then how would I unblock the user at some later time, if I changed my mind?  And how do I detect if my operation succeeded, in case the proxy couldn't process my block/unblock request?

This is something we have mentioned in the Open issues section
(Appendix B). Here I see two alternatives:
1) "Offline" mechanism for unblocking user identities (e.g. web
interface where one could remove blacklisted destinations)
2) "Online" mechanism for unblocking user identities. For this, I
believe the UA should retrieve the "blacklisted destinations", select
one or several destinations and send a F00B4r message with:

Reason: block; cause=1 or 2; text="unblock";
uri="sip:user at domain.com"; Expires=0
or
Reason: block; cause=3; text="unblock"; uri="sip:user at domain.com"; Expires=XYZ

>
> This seems more like a use-case for an event-package, where one can send a PUBLISH to block/unblock users, or even a Subscribe to view the current list.  The tricky part with that is that for some incoming calls there is no caller-id/source-AoR for me to ask to be blocked or unblocked.  But since for that to be the case requires the proxy to essentially be a B2BUA (to provide privacy anonymization, or in 3GPP's case to remove and store the PAI), then one could argue the PUBLISH can be sent to that same upstream B2BUA which can insert that info if it still has it. (ugly, but possible)  Hmmm... I'll have to think about that issue more.
>

The event-package seems to be a reasonable alternative. And yes, when
the called UA cannot resolve the calling identity, the server needs to
fetch the actual identity of the caller (See section 3.2). In other
words, the UA would ask the server to "blacklist the identity that
initiated dialog X".

> Some other comments on your draft:
> 1) You show the Reason header being removed by the Proxy.  While that may make sense for some cases, for being out on vacation it does not - I *want* the UAC to see it.

I believe the header can reveal sensitive information for an attacker:
permanent blocking vs temporal blocking (and the expires).

Cheers,
-- 
Victor Pascual Ávila