[e2e] Fighting SPIT on a cell phone

[bmanning@vacation.karoshi.com]

On Fri, Jan 11, 2008 at 04:57:23PM +0100, Pars Mutaf wrote:
> Hi,
> 
> On Fri, 2008-01-11 at 15:25 +0000, bmanning at vacation.karoshi.com wrote:
> > you are making an assumption about the persistance
> > of the binding between an IP address and a given interface.
> 
> The IP address can be a mobile IP address for example. But 
> other solutions are certainly possible.

	3ff3:0:478::42  - is this mobile or fixed? what is the
		lease time?   the point i was trying to make 
		was that an IP address is WHERE you are in a
		topology, not WHO you are.

> > you seem to be making an assumption about the ability to 
> > algorithmically determine unwanted content ... 
> 
> In my vision, if Mr. X who was given the SIP URI 'x' starts 
> to SPIT on my phone, I (the user) can cancel the SIP URI 'x'. 
> Mr. Y can still call me because he was returned another SIP 
> URI.

	let me try and be more clear.  who or what makes
	the determination that Mr.X is "spit"ing on your 
	telephone?  
> 
> This idea of "disposable cell phone number" is already in 
> use today. 
> We are proposing a protocol for distributing disposable 
> SIP URIs from the cell phone, on an on-demand basis.
	
	ah ... you are proposing to augment SIP call 
	establishment w/ a challange/response ...

> 
> > which is 
> > a much harder problem and not (IMHO)  something usually 
> > done at the transport layer.
> 
> Why transport layer?

	the e2e list was focused on IP end 2 end, not application
	layer end 2 end.  SIP is (by definition) an application
	that runs on top of IP.

> 
> Thanks!
> pars
> 
> 
> 
> > --bill
> > 
> > 
> > On Fri, Jan 11, 2008 at 02:24:39PM +0100, Pars Mutaf wrote:
> > > Hello,
> > > 
> > > I want to leave my cell phone number (SIP URI) on a discussion
> > > forum, or web page, blog, craigslist, phonebook, facebook etc. 
> > > But wish to avoid SPIT (SPam over Internet Telephony). A solution 
> > > is presented below (with variations called weak, strong).
> > > 
> > > Looked like acceptable end2end-interest topic (sorry if not).
> > > Comments are appreciated.
> > > 
> > > Regards,
> > > Pars Mutaf
> > > 
> > > 
> > > 1. Weak solution
> > > 
> > > I leave the IP address of my cell phone but not a SIP URI. Interested
> > > party sends a request to my phone. My phone generates a random SIP URI
> > > and returns a different SIP URI to each querier.
> > > 
> > > If I receive SPIT to the SIP URI 'x', then I can cancel it. Since 
> > > each requestor is returned a different SIP URI, legitimate parties can 
> > > continue to call me or send SMS.
> > > 
> > > Since the SIP URI 'x' was canceled, a SPITer can request another one
> > > and still send me SPIT. To avoid this attack, the querier can be
> > > requested to solve a hard challenge e.g. a CAPTCHA. A SIP URI will be
> > > returned only after the querier user provided the solution. The
> > > difficulty of the CAPTCHA can be adaptively tuned by the target host.
> > > 
> > > When done, i.e. the desired phone call is received, the target user
> > > can stop receiving requests to the indicated IP address.
> > > 
> > > 
> > > 2. Strong solution
> > > 
> > > I leave the IP address of my phone but not a SIP URI. I want to
> > > receive phone calls or SMS only from people that I know. Interested
> > > party sends a request to my phone. My phone displays a message with 
> > > the requestor's name e.g.:
> > > 
> > >   "Alice Collins requested phone number. Accept? [YES/NO]"
> > > 
> > > If I accept, my phone generates a random SIP URI and returns it to the
> > > querier.
> > > 
> > > This solution requires human name certification.
> > > 
> > > An attacker can send continuous bogus requests to the target IP
> > > address and make the target phone continuously display the above
> > > message, annoying the target user. This attack can be defeated by
> > > requesting the querier user to solve a hard CAPTCHA before his request
> > > can be displayed at the target host's screen. The difficulty of the
> > > CAPTCHA can be adaptively tuned by the target host.
> > > 
> > > ==
> > > Comments are appreciated either here or please subscribe to:
> > > https://www1.ietf.org/mailman/listinfo/humanresolvers
> > > 
> > > If you find the problem interesting but have another solution
> > > you are also welcome of course.