[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] New Internet Draft for Caller Identity Blocking
How is this draft different from previously investigated approaches?
http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00
Ciao
Hannes
>-----Original Message-----
>From: sipping-bounces at ietf.org
>[mailto:sipping-bounces at ietf.org] On Behalf Of Hadriel Kaplan
>Sent: 02 March, 2009 17:12
>To: Avasarala Ranjit-A20990; sipping at ietf.org
>Subject: Re: [Sipping] New Internet Draft for Caller Identity Blocking
>
>
>Hi Ranjit,
>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.
>
>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 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.
>
>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.
>2) You describe the Reason header being inserted in
>BYE/CANCEL, but in the example it's in a 4xx. Sending it in a
>4xx failure response should be explicitly included, imho, even
>though I think the Reason-header RFC didn't allow it (for some
>whacky reason).
>3) You add an Expires parameter (which should be lower-case,
>by the way), and say if it's value is "99999" then it's
>permanent, but meanwhile in one example a value of "604800" is
>used for being on vacation. So clearly 99999 is not max.
>Seems to me "99999" is a very small number, just slightly
>longer than a day. :) Maybe just make it 4294967295 (an
>unsigned long, 2^32-1, 136 years).
>4) In the security section, it mentions integrity protection
>to prevent snooping of messages when using this header.
>AFAIK, integrity protection provides no eavesdropping
>protection (that would be encryption); not that I can see why
>it matters if someone snoops on this header anyway. You also
>later cite TLS and S/MIME - I think you might as well remove
>S/MIME since it's a waste of 6 characters in toner/ink if
>anyone prints this draft out. ;)
>
>-hadriel
>
>________________________________________
>From: sipping-bounces at ietf.org
>[mailto:sipping-bounces at ietf.org] On Behalf Of Avasarala Ranjit-A20990
>Sent: Monday, March 02, 2009 3:45 AM
>To: sipping at ietf.org
>Subject: [Sipping] New Internet Draft for Caller Identity Blocking
>
>Hi All
>I have just submitted an I-D on blocking caller identities
>during ringing and call termination phases by extending SIP
>Reason header to be included in SIP BYE and CANCEL methods.
>Please review and comment
>The URL of the draft is:
>http://www.ietf.org/internet-drafts/draft-avasarala-sipping-rea
>son-header-dynamic-icb-00.txt
>Thanks
>Regards
>Ranjit
>_______________________________________________
>Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP Use
>sip-implementors at cs.columbia.edu for questions on current sip
>Use sip at ietf.org for new developments of core SIP
>