[VOIPSEC] Watering down VoIP security expectations

Fri Mar 10 14:59:47 GMT 2006

Hi!

I believe that VoIP security would be done by layers. Each layer of security
will then be marked on the SIP signalization of the setup call and the
receiving "systems" (SIP Proxy, IP Terminal, User) will have the hability to
screen off if the call doesn't comply to the criteria. Each layer would had
some information to the SIP packet. Each system would trigger some decision
based on the existence and value of this information. The user should be
notified by the appropriate info on the LCD/ring type if the call get
through all the other systems.

The levels could be:
- remote user authenticated (no/low cipher/high cipher)
- remote sip server/proxy verified (no/pki tree/...)
- signal between sip server (clean/TLS/encrypted A1/encrypted A2/...)
- stream between sip proxies (clean/SRTSP/encrypted B1/encrypted B2/...)
- ...

Each administrator would be able to configure their criteria based on their
own designed needs. On some institutions someone could require all, while at
home people could only require some or none... 

THE SECURITY NEEDS ARE NOT THE SAME FOR EVERY ONE!

I would be happy to know if someone is working on some similar approach.

Rui Ribeiro
racr at fccn.pt

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Tobias Glemser
Sent: sexta-feira, 10 de Março de 2006 14:19
To: voipsec at voipsa.org
Subject: Re: [VOIPSEC] Watering down VoIP security expectations

Mark,

 > When attempting to filter Spam over Internet Telephony (SPIT), it is  >
much harder for VoIP vendors or ancillary product vendors to design  >
content filters based (..)

I totally agree with you that the inspection of SPIT is way more difficult
than the inspection of SPAM. By nature a "Anti-SPIT-System" 
will never be able to analyze the content of a call. But, and this is were
SPAM and SPIT can be treated the same, this system could analyze the headers
of each call.
In our researches we recognized, that many end-devices accept almost every
rubbish content of headers, as long it's syntactically correct. 
Even MUSTs of some RFCs are just ignored.
In my opinion, this would be a first attempt to filter some SPIT: Check the
validity of all header information.

Another point is, that your phone normally only accepts incoming calls from
its very own SIP-Proxy (this is how it _should_ be, many phones ring even if
they're not logged on to any SIP-Proxy).
Calls without costs for the connection are normally only available between
customers of one SIP ServiceProvider and other cross-connected networks.
So if someone who wants to send SPIT, he wants to do it for free, of course.
In other words, he has to have a valid login to the ServiceProvider you
("the target") is connected to. It's not that hard for SPs to recognize
SPITTERs on their systems very fast and efficient, e. g. by providing a
"I've been SPITtey by.." webform for their customers.

To put this together:
1. Your phone only accepts incoming calls from your SIP-Proxy.
2. -> a SPITTER has to be on the same or a cross-connected SIP-Provider to
make the call without costs 3. -> he has to have a valid account 4. -> the
SP has to establish barriers at the registering process (e. g. 
one money transfer from a bank account, even if the SIP-Provider offers his
services for free) 5. -> the SP has to establish good SPIT reporting systems

This would mean to a SPITTER
1. If he wants to make free calls, he has to get through this registration
process 2. He has to register quite often whith changing bank accounts 3. He
has to make sure that he can not be traced back by the authorities because
he sent SPIT and transfered money from his bank account 4. He could attack
the end-device to avoid that only calls from the SIP-Proxy are accepted (e.
g. by DNS-poisoning), but this seems a little bit to extensive 5. He could
pay for the call at his POTS provider elsewhere

So my second conclusion for this day :) :
Maybe the solution to reduced SPIT does not exist in only technical, but
organisational concepts.

Cheers,

Toby

Mark Teicher wrote on 10.03.2006 14:20:
> If we go by SPAM by the numbers: 55 is the percentage of companies that
have not implemented spam filtering due to the fact that they are afraid
legitimate messages may be blocked, 19 is the percentage of opt-in,
legitimate electronic mail from electronic newsletter publishers that never
reach subscribers due to over-active spam filters, 400 is the number of
domain names used by a typical spammer (source: National Spam Mail Abuse
Association). For SPAM it is accurate to state that a majority of the
electronic mail people receive can be broken out into various categories
(i.e. personal correspondence, work-related correspondence, opt-in
newsletters, bulletins, mailing lists, e-mail alerts).   
> 
> When attempting to filter Spam over Internet Telephony (SPIT), it is much
harder for VoIP vendors or ancillary product vendors to design content
filters based on tell-tale calling patterns, war dialers, short call
durations, patterns of spoken words or phrases or communicating with someone
who legitimately has Tourette's Syndrome, faint calls, calls originating
from people on headsets utilizing a public restroom at an airport,
originating call tracking, poor call quality, etc.  It is much different
problem than addressing SPAM, although most argue it is a combined problem,
when it really isn't.  Although there are probably people who post to the
list that have written or published ways of reducing SPIT in a converged
network environment, hopefully they will have something helpful to
contribute.
> 
> 
> 
> 
> On Fri, Mar 10, 2006 at 10:16:00AM +0100, Tobias Glemser wrote:
>> So my conclusion is this:
>> The SPAM/SPIT problem will never be beaten, we can only try to 
>> develop better and better solutions to eleminate as many SPAM/SPIT as 
>> possible before it reaches the user. This is where we can evolve, 
>> just have a look at Anti-SPAM Boxes today. The race has begun but it will
never finish.
> 
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] 
> On Behalf Of Ari Takanen
> Sent: Friday, March 10, 2006 4:51 AM
> To: Tobias Glemser
> Cc: voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Watering down VoIP security expectations.
> 
> Hello all,
> 
> Good conclusion there Tobias. There is no technical solution for SPAM 
> as it is not a technical problem. It is a problem in all free, open 
> and un-moderated services. There is no way people can beat SPAM in 
> "Free Internet Telephony", and that is exactly why there is a business 
> opportunity in VoIP. People will still pay for good service.
> 
> The best prevention methods that aim at this focus on providing:
> 
> - reliable identity (SIM cards in mobile phones is one good idea)
> - generic legislation, and specific contract practices between parties
> - trust relationships between VoIP providers
> 
> So if someone spams you from Romania, you should be able to know who 
> to blame. The carriers will blacklist VoIP providers and servers that 
> do not act according to best practices, and hopefully someone will sue 
> the negligent service providers. Problem solved.
> 
> This still leaves SPAM bots, and other attacks where a system is 
> compromised and a trojan is installed on the system. This is a reason 
> why you should use reliable platforms and devices. List of Codenomicon 
> recommended vendors is available on our web site!
> 
> /Ari
> 
> PS: Update your VoIP devices regularly!
> 
> On Fri, Mar 10, 2006 at 10:16:00AM +0100, Tobias Glemser wrote:
>> So my conclusion is this:
>> The SPAM/SPIT problem will never be beaten, we can only try to 
>> develop better and better solutions to eleminate as many SPAM/SPIT as 
>> possible before it reaches the user. This is where we can evolve, 
>> just have a look at Anti-SPAM Boxes today. The race has begun but it will
never finish.
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org