Subject: [Rucus] FW: I-D on dynamic caller ID blocking

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 25 Feb 2009 20:43:58 +0800

> Hi All
> 
> I intend to submit the attached Internet draft to IETF.  This draft is
> based on the 3gpp contribution S1-090067 to 22.173 (latest one) that
> talks about dynamic blocking of incoming communications. 
> 
> Abstract:  This I-D extends the SIP Reason header defined in RFC 3326
> to allow terminating users (Caller	d users) to dynamically block
> the callers from further calling. The extended SIP Reason header
> suggests a new protocol value "block" with options for blocking the
> callers either permanently or for a temporary period
> 
> Permanent block:  Reason: block; cause=1; text="Telemarketer";Till=0
> Temporary block:   Reason:block; cause=2;
> text="OOO";Till=01032009"09:00:00   - Implies till when the block
> should be effective.
> 
> This reason header can be appended to either CANCEL or BYE methods (as
> mentioned in RFC 3326) for blocking caller either during alerting or
> terminating phases of SIP.
> 
> Comments welcome
> 
>  <<draft-avasarala-sipping-reason-header-dynamic-icb-00.txt>> 
> 
> Thanks
> 
> Regards
> Ranjit
>

---

From: Victor Pascual Ávila <[email-masked]>
Date: Wed, 25 Feb 2009 21:09:38 +0100

Hi Ranjit,

On Wed, Feb 25, 2009 at 1:43 PM, Avasarala Ranjit-A20990
<[email-masked]> wrote:
> I intend to submit the attached Internet draft to IETF.  This draft is based
> on the 3gpp contribution S1-090067 to 22.173 (latest one) that talks about
> dynamic blocking of incoming communications.
>
> Abstract:  This I-D extends the SIP Reason header defined in RFC 3326 to
> allow terminating users (Caller        d users) to dynamically block the
> callers from further calling. The extended SIP Reason header suggests a new
> protocol value "block" with options for blocking the callers either
> permanently or for a temporary period
>
> text="OOO";Till=01032009"09:00:00   - Implies till when the block should be
> effective.
>

I like this draft. Just a quick question:

"the called user (UAS) can block the incoming caller (UAC) during
ringing phase by looking at the number displayed on the phone"

"Looking at Caller ID, the called user decides to block the calling
user from further calling"

What are you actually blocking?
What if the called party is presenting a forged Caller ID? Please take
a look at [1].

[1] http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important

Any clarification would be appreciated,
-- 
Victor Pascual Ávila

---

From: Victor Pascual Ávila <[email-masked]>
Date: Wed, 25 Feb 2009 21:13:47 +0100

On Wed, Feb 25, 2009 at 9:09 PM, Victor Pascual Ávila
<[email-masked]> wrote:
> What if the called party is presenting a forged Caller ID?

Edit: "calling party"

Cheers,
-- 
Victor Pascual Ávila

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 26 Feb 2009 13:56:43 +0800

Hi Victor

Thanks for the comments..

If the calling party is presenting forged identity then the called user relies on the proxy server to fetch the correct identity and do the blocking. So whenever a BYE or a CANCEL request is triggered from the called user, the server needs to check the identity before adding the identity to the black list for the called user.

This way even though the identity of the calling user is unknown or forged, it can still be blocked.

Should I add all these details to the draft?

Thanks

Regards
Ranjit

-----Original Message-----
From: Victor Pascual Ávila [mailto:[email-masked]] 
Sent: Thursday, February 26, 2009 1:44 AM
To: Avasarala Ranjit-A20990
Cc: [email-masked]
Subject: Re: [Rucus] FW: I-D on dynamic caller ID blocking

Edit: "calling party"

Cheers,
--
Victor Pascual Ávila

---

From: "Charzinski, Joachim (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 26 Feb 2009 08:25:23 +0100

Hi Ranjit,

I think it is important to deal with this sort of indirect 
blacklisting attack in the draft. It should be made clear 
that either (1) blocking of caller IDs is only allowed on 
verified caller IDs - but this approach only helps if all 
non-verified caller IDs are blocked by default, otherwise 
spitters would just make sure their IDs cannot be verified, 
or (2) the system is susceptible to indirect blacklisting 
attacks, i.e. an attacker can use a victim's caller ID and 
misbehave to get the victim blocked from the network. In 
some cases, this might be considered acceptable, but people 
should be aware of the effect when chosing this approach. 

However, as your draft focuses on the "how" rather than 
the "why" and the architectural and regulatory framework, 
this discussion should rather go into a framework document. 
But what should be discussed in the "reason-header" draft 
is the question of "when" to apply reason headers. Some 
people argued that it is counter-productive to send reason 
headers to spitters because that only helps them increase 
their efficiency. Your example (Sec. 3.2) allows spitters 
to schedule retries instead of having retrying effort or 
just giving up. 
In addition, the example of Sec. 3.2 is not considered 
state of the art in security - most people agree you should 
not leave absence notes like this because these notes give 
important hints for social engineering. 

One last remark: if you include a reason such as "Telemarketer" 
in a signalling message, this should be accompanied by a complaint 
address giving a hint to a blocked caller how to release the 
blocking in case the reason is considered incorrect. 
An exception from this would be if telemarketers were obliged 
(e.g. by law) to signal the nature of their call in the INVITE 
message and it was understood in the network that callees can 
opt out of telemarketing calls (potentially paying more for their 
phone service in return). In that case, it might be clear to the 
caller that the reason code relates to their initial call-intent 
code...

Best regards

	Joachim.

----------------------------------------------------------
Joachim Charzinski

Nokia Siemens Networks
Research, Technology and Platforms 
Research & Technology / Network Evolution
 
St.-Martin-Str. 53
Post box: D-80240 Muenchen
D-81541 Muenchen
Germany
Tel: +49 89 636 79902

[email-masked] 
http://www.nokiasiemensnetworks.com/global/

Think before you print

Nokia Siemens Networks GmbH & Co. KG
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRA 88537
WEEE-Reg.-Nr.: DE 52984304

Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH
Geschäftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Avasarala Ranjit-A20990
Sent: Thursday, February 26, 2009 6:57 AM
To: Victor Pascual Ávila
Cc: [email-masked]
Subject: Re: [Rucus] FW: I-D on dynamic caller ID blocking

Hi Victor

Thanks

Regards
Ranjit

-----Original Message-----
From: Victor Pascual Ávila [mailto:[email-masked]] 
Sent: Thursday, February 26, 2009 1:44 AM
To: Avasarala Ranjit-A20990
Cc: [email-masked]
Subject: Re: [Rucus] FW: I-D on dynamic caller ID blocking

Edit: "calling party"

Cheers,
--
Victor Pascual Ávila
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus