© 2006 NEC Corporation - Confidential Ｐ age 1 May 2008 - 1 SPIT: Do not wait until it is too late Jan Seedorf, Saverio Niccolini (jan.seedorf_at_nw.neclab.eu)

© 2006 NEC Corporation - Confidential

Ｐ age <date> 1May 2008 - 1

SPIT:Do not wait until it is too late

SPIT:Do not wait until it is too late

Jan Seedorf, Saverio Niccolini

(jan.seedorf_at_nw.neclab.eu)

NEC Laboratories Europe (NLE), Network DivisionNEC Europe Ltd., Heidelberg, Germany

2008/05/21 – TERENA Networking Conference 2008May 2008 - 2

Outline

• Voice-over-IP and the SPIT Threat

• A Protection Framework based on User Interaction

• Approaches for SPIT Mitigation

• Research Prototype

• Conclusions


Outline





• Conclusions


Introduction to Voice-over-IP (VoIP)

• What is Voice-over-IP?– The transmission of (digitised) voice over IP-based networks– Separation of signalling and media transfer

Signalling: SIP (Session Initiation Protocol)Media: RTP (Real-Time Transport Protocol)

• SIP (Session Initiation Protocol)– an application-layer signalling protocol for (multimedia) sessions– supports

Mobility of usersMedia parameter negotiationSession Management


Voice-over-IP: Market Growth

• VoIP traffic growth is continuous [Stanford Group]

– 100% in 2006

– forecast > 50% through 2009 • 50% of all global telecoms traffic is

done over IP [Research&Markets]

– mainly as transit traffic, and this will increase to 75% in a few years time

• 70% of enterprise telephony market will be VoIP by 2010 [Dell’Oro]

• NGN is approaching– see standards: 3GPP, TISPAN, etc.– IMS will be the core of NGN

• IMS will become mainstream around 2010 [Informa]

– IMS is SIP-based– SIP applications are not only VoIP

e.g. IM, Presence, IPTV, etc.

• What is wrong with all this?

– see next slide


VoIP Security Challenges• Increase in Complexity

– SIP-based infrastructures are more complex than traditional networks

– Difficult to quickly identify the cause of the problem and respond to user’s complaints

• Decrease in Security and Trust– VoIP Signalling over IP-networks implies

Spoofing, sniffing, impersonation, ...malicious attacks (viruses, botnets, …)Vulnerable devices

– SIP-based infrastructures are vulnerable to many attacks

Denial of Service attacksInterception and ModificationAbuse of Service (Fraud)Social attacks

(SPam over Internet Telephony, SPIT) Need for fast detection and reaction to security and trust threats


Spam over IP Telephony: SPIT• Fear of SPIT

– With VoIP, costs per call initiation will reduce dramatically– Very low costs are the main reason why e-mail spam is proliferating

in the Internet age Reasonable to assume that SPIT will become a problem when VoIP

gets massively deployed

• SPIT is much more obtrusive than e-mail spam– E-mails get “pulled” from a server by the user; VoIP calls are

“pushed” to the user– your telephone might ring in the middle of the night…

• Most successful approaches against spam from the e-mail world will probably not work– Content filtering needs to be done in real-time Innovative solutions are needed

“Don't be left out, join millions of men in the revolution …“


Outline





• Conclusions


5-stage Protection Framework

• Stage 1:– Non-intrusive: Filtering SIP messages

without any user-interaction• Stage 2:

– Caller interaction: Protecting the callee of a call by testing the trustworthiness of the caller in an interactive way

• Stage 3:– Feedback before call: Asking the callee

regarding the identity of the caller• Stage 4:

– Feedback during the call: Indicating to the system that the current call is unsolicited

• Stage 5:– Feedback after the call: Marking a call as

unsolicited once the session has terminated

Protection against SPIT at different stages of a call


Outline





• Conclusions


No Interactions With Call Participants (I)

• Blacklists / Whitelists– simple mechanism but identity of the

caller is the key– white lists (identities allowed to call)– black lists (identities that should be rejected)– members of white lists and black lists may be configured

• Considerations– strong identity is standardized by IETF– white lists require explicit permission for every identity

– initial contact is the problem

– black lists can easily be circumvented if there is an infinite supply of SIP identities

– service provider willing to give away identities to attract customers

– circumventing a white list is more difficult– a spammer has to know an identity from the list to be able

to spoof a call

Caller


No Interactions With Call Participants (II)

• Pattern/Anomaly Detection–very general–deciding, based on patterns and signatures whether the

incoming call is unsolicited or not• Considerations

–like all methods working with patterns or statistical data–suffers from the drawback of possibly generating

false positives–legitimate calls being blocked

• Many methodologies–NEC is working on pattern/anomaly detection specific

for multimedia DoS/SPIT


Caller-side Interactions (I)

• Computational Puzzles– currently being standardized by the IETF

– just for SIP, see draft-jennings-sip-hashcash

– giving the caller's terminal a resource-consuming task to perform before establishing the call

– reduce the potential of SPIT generators

• Considerations– attackers use botnets to distribute the cost of

computing puzzles– limits the effectiveness of the solution

– embedded VoIP devices have limited computational power

– a computational puzzle is easy to solve for a current desktop PC might be too complex for an embedded device to be solved within an acceptable amount of time


Caller-side Interactions (II)• Turing Test

– conversational method to tell humans and computers– the judge is a human being– similar tests (still belonging to the class of Turing tests) are used to secure

websites from being accessed by bots– also called CAPTCHAs (Completely Automated Public Turing Test to Tell

Computers and Humans Apart)– the judge is a computer instead of a human

– most CAPTCHAs are visual although audio CAPTCHAs exist as well

• Considerations– audio CAPTCHAs are suited for SPIT prevention– they are more intrusive than methods which are invisible to the caller itself


Callee Interrupted by Call

• Consent-based Communication– user A authorises user B, the first time user B tries to contact user A– it solves the first-contact problem but introduces a delay until the first

call can be placed– a framework for consent-based communications combined with lists

is currently being standardized by the IETF for the SIP protocol– see draft-ietf-sipping-consent-framework

• Considerations– another form of disturbance if users receives many consent requests

Caller

Do you want to authorizethis user to call you?

Deny him for callingAuthorization grantedadd to buddy list


Callee Receives Call

• Content Filtering– blocking email spam is essentially based on content analysis– cannot be fully applied to prevent SPIT

– the content is very different (ASCII text versus coded speech)– voice recognition is not yet fully solved– consuming a lot of computational resources– the content is not available when the check needs to be performed

– voice calls are real-time and emails are not real-time– could be useful to prevent SPam over Instant Messaging (SPIM)

– even if the length of an IM is much shorter than the one of a email

– useful application if voice mails are considered– the content is available there

– the receiver has been disturbed by a ringing phone– disturbance for the user is high


Feedback From Callee After Call

• Basic idea– each user who receives an unsolicited call reports it to an

identification system– it can be the SIP Proxy Server itself (UA Proxy)– using a button on the user interface of the client (prototype

implementation in figure)

• Active work in this area in IETF SIPPING working group– draft-niccolini-sipping-feedback-spit– draft-wing-sipping-spam-score– Requirements and parameters to be sent back for identification– Overview of possible methods to send feedback

– Additional Header– Event Package


Outline





• Conclusions


A Research Prototype for SPIT Protection: VoIP SEAL

• VoIP SEAL covers different stages with different modules

– mix of open and closed loops

• Stage 1 modules are combined using a scoring system

• Stage 2 modules are combined based on the output of the previous stage

• Stage 3/4/5 use the information coming from feedbacks to work in collaboration with Stage 1 modules

Mod

ule

1

Mod

ule

2

Mod

ule

n

...

Scoring System

+ + +

Stage 1

Module 1

Module 2

Module n

... Dis

patc

her

Stage 2

accept /reject

accept /reject

Feedback ProcessingStage 3/4/5

TerminalsVoIP SEAL


VoIP SEAL : Blocking SPIT – Interactive(stage 2: simple Turing test)

SIP Server withVoIP SEAL

[email protected]

[email protected]

suspicious caller:additional tests

Too high SPITblock the call

Close to zero:process further or

accept the call

1. Energy level of conversationduring greeting/question?


Advanced customization / personalization

Selecting - Stage-2 test

Black-/Whitelist - administration


Distributed Detection Scheme

VoIP SEAL - SBC

• Protection against Malicious Threats– (D)DoS attacks, Malformed Messages, …

• Identification of Unsolicited Communication (SPIT)

– Global Blacklist, Call-Rate Detection– Simultaneous Calls, Statistical Analysis, …

• Other Anomaly Detection & Prevention– HoneyVoIP

Alice SIP

device

VoIP SEALSBC

SIP infrastructure

[Internet / outer network (unprotected)]

[operator / customer network(VoIP SEAL protected)]

Attacker

Tom(unprotected)

HoneyVoIP

VoIP SEAL – AS• Advanced Functionality

– Cooperation of Modules– Distributed Scoring

• Customisation and Personalisation– Personalised Black/White Lists– Call Behaviour based on User Preferences

• Advanced Attack Detection (Stage 2)– Touring Test, Simple IQ test, Greylisting, …

VoIP SEAL - AS

VoIP SEALVoIP SEAL

VoIP SEAL

Bob legacy device

VoIP SEAL


VoIP SEAL: Modules & Recent Enhancements

• Greylisting– a user is asked to call again after

a certain time period• Advanced CAPTCHA tests

– protecting against Denial-of-Service and social attacks

• Dispatcher module (stage 1)– decides to pass messages to

other stages depending on their content

• Integration of a VoIP Honeypot• Water-fingerprinting

– advanced statistical call-frequency analysis to detect unsolicited messages and prevent against Denial-of-Service attacks

• Cross-layer malicious packet filtering – correlating the signalling and

voice channel (SIP and RTP)• Detection of malformed messages

– detecting messages that exploit vulnerabilities in SIP implementations

• Interfaces for user customisation / personalisation– Enabling configuration of

protection profiles (e.g., whitelists, blacklists, other modules) on a per-user basis

• Distributed call rating scheme– sharing information on malicious

messages and unsolicited communication with other SIP-entities


Outline





• Conclusions


Conclusion

• Signalling over IP-networks introduces new threats to telephony–Increased complexity–Many security challenges

• Spam over IP Telephony (SPIT) is expected to become a severe threat for VoIP business–SPIT is more obtrusive than e-mail spam–Today‘s SIP networks are not prepared for this threat–Innovative countermeasures are needed


Conclusion (II)

• Protection can be done at different stages of a call–5 stage framework based on user-interaction–Various protection methods are possible at each stage

• No single technique will protect against all threats–Combination of different protection modules is necessary–Integration of new methods against new evolving threats

must be possible

• Research Prototype has been implemented–VoIP SEcure Application Level firewall (VoIP SEAL)

Modular, flexible and extensible platform


IPTComm 2008:Services and Security for Next Generation Networks

The 2nd Conference on Principles, Systems and Applications of IP Telecommunications(featured info: VoIP Security workshop now federated with IPTComm)

www.iptcomm.org

Important dates:Paper submission: April 9th, 2008

Notification of acceptance: May 2nd, 2008Camera ready papers due: May 30th, 2008

Conference dates: July 1st and 2nd, 2008Conference Location: Heidelberg, Germany

Conference Co-ChairsSaverio Niccolini (NEC Laboratories Europe)

Pamela Zave (AT&T Labs Research)

TPC Co-chairsHenning Schulzrinne (Columbia University)

Radu State (INRIA-LORIA)

Scope: Convergent Services VoIP, NGN and IMS Security Management, Resilience and QoS Billing and Regulatory aspects


Contact Details:

Jan Seedorf, Research Scientist (jan.seedorf_at_nw.neclab.eu)

NEC Laboratories Europe (NLE), Network DivisionNEC Europe Ltd., Heidelberg, Germany

Documents

© 2006 NEC Corporation - Confidential Ｐ age 1 May 2008 - 1 SPIT: Do not wait until it is too late Jan Seedorf, Saverio Niccolini (jan.seedorf_at_nw.neclab.eu)