[e2e] Fighting SPIT on a cell phone
bmanning at vacation.karoshi.com
Fri Jan 11 07:25:09 PST 2008
you are making an assumption about the persistance
of the binding between an IP address and a given interface.
you seem to be making an assumption about the ability to
algorithmically determine unwanted content ... which is
a much harder problem and not (IMHO) something usually
done at the transport layer.
On Fri, Jan 11, 2008 at 02:24:39PM +0100, Pars Mutaf wrote:
> 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.
> 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
> 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:
> If you find the problem interesting but have another solution
> you are also welcome of course.
More information about the end2end-interest