Unsolicited Communication in the NGN - Directory … 1 ETSI Security Workshop Unsolicited Communication in the NGN Overview of Status and Activities in different SDOs

Ｐage <date> 1 ETSI Security Workshop

Unsolicited Communicationin the NGN

Overview of Status and Activities indifferent SDOs

Thilo EwaldResearch Scientist

NEC Laboratories EuropeNEC Europe Ltd., Heidelberg, Germany

[email protected]

© NEC Corporation 2006(200604)ETSI TISPAN – The Home of NGN StandardsMay 08 - 2

Table of content• Problem statement

– Problem Statement & Definition– Forecast of next generation SPAM?– Technical means of countering UC

�Technical means for identifying UC– Handling & Preventing of UC– Standardization of PUC

• Ongoing work– IETF– ITU– 3GPP– TISPAN

• Questions and Answers


Problem statement

What is SPIT, call/multimedia-SPAM unsolicitedcommunication and how this be faced by technical

means?


Problem Statement & Definition• SMS/MMS/call-SPAM, multimedia-SPAM, SPIT (SPAM over Internet Telephony), …

– Similar wording for the same problem� Unsolicited communication (UC)

– Biggest problem:� UC perception is highly personalized

• UC based on human->human or machine->human communication– UC classification: social threat

� (bulk) unsolicited communication, mainly spread advertisement� Directed advertisement or VoIP phishing (Vishing)

– Results in more stress at home and in office� More difficult to establish communication

� e.g. phone switched off to prevent it from ringing� Voice mailbox filling with voice spam messages� Become sever threat as attack of the availability of the NGN

Good call

Riiing...Riiing...

SPITcalls


Forecast of next generation SPAM?• NGN devices will become ubiquitous as em@il accounts nowadays are

– Number of subscribers will increase dramaticallywithin the NGN

• Today em@il SPAM keeps on increasing– 3600 spam messages per day for a small enterprise– 100 SPAM messages per day for a end users

• Voice SPAM in Germany– 150.000 identified numbers [Bundesnetzagentur]

• Auto Dialer for expensive numbers / Phising– 300.000 identified numbers [Bundesnetzagentur]

• Conclusion– UC is expected to become a sever threat in the NGN / for the NGN user

em@il SPAM filter results from a small corporate network


Technical solution against UC• Identification

– Based on background information (lists) or call history (non intrusive)– Based on patterns analysis in the signalization (non intrusive)– Based on caller based testing (intrusive)– Based on feedback from callee (intrusive)

• Handling & Reacting– Reroute according to operator and user preferences

� i.e. to mailbox– Block / intercept unsolicited communication

� Only possible by strict contract or last decision at user premises• Preventing

– Reacting in behalf of the user� Only possible by having a per user profile for reacting on UC

– Reacting for protection of the network� If UC becomes a threat against the availability of the network itself


Technical means for identifying UC• Non-intrusive test

– Blacklisting / white listing– Message/Call rate analysis– Simultaneous call analysis– Call behavior analysis– Statistically analysis

• Caller Interactions– Touring test– DTMF check– Greylisting

• Feedback before call– buddy list integration– consent-based communications– Pure Signalization and let user choose

• Feedback during call– SPIT hang-up button

• FB after call– service center– Web-Front-end– Intelligent user clients

Stage 1:non-intrusive

Stage 2:caller interaction

Stage 3:feedback before call

Stage 4:feedback during call

Stage 5:feedback after call

know

ledg

e ba

se

callee

callee

system

system

feedback

system

General &Personalized

Personalized


Handling & Preventing of UC• Technical means for handling UC

– Explicit handling by re-routing or blocking UC� Can be done in the network or at the user device

– Mark UC attempt for later handling� Distributed solution for load-balancing, specialization of identification, etc.� Give final decision point back to the user

• Problem: regulatory aspect of communication– No operator is allowed to intercept any kind of communication attempts

� Only with contractual power operators are allowed to react in behalf of thecustomer to communication attempts

• Implicit vs. explicit prevention UC– Explicit prevention by handling the communication request at the user

premises e.g. UE or home-gateway� With or without the assistance of a service from the network

– Implicit prevention by handling the communication request within thenetwork e.g. as additional service� Better technical solutions for identifying and handling UC and personalization of

the users UC profile


Standardization of PUC

Caller (SPITer) Callee (Bob)

Core network

mark

Accessnetwork

Identify

mark

UserprofilesIdentify

mark

• PUC – Prevention of unsolicited communication– Recommendations which network entities / interfaces should be enhanced

by PUC functionality� SDO dependant

– Standardization of marking of UC identified communication attempts� Protocol extensions are needed

– Standardization of common UC user profile scheme

Accessnetwork

PUC functionality

Identify

Identify

PUC functionality PUC functionality


Ongoing work in the SDOs

IETF, ITU, 3GPP, TISPANOther..


Study of preventing UC (TR - WI07025)

2005 2006 2007 2008

sipping-spam (SIPPING WG draft) RFC 5039niccolini-sipping-spitstop

wing-sipping-spam-scoreniccolini-sipping-feedback-spit

tschoefening-sipping-framework-spit-reduction

froment-sipping-spit-requirementstschoefening-sipping-spit-policy

dhoi-sipping-experiments-spit“SPITSTOP” discussion

PUC (TS)

Study on SMS MMS spam (TR)

X.ocsip – overview studyX.csreq – requirements study X.1231

X.fcsip – framework study

tschofenig-sipping-captchajennings-sip-hashcash

Overview of UC work in different SDOs

PUCI (TS)


UC in the IETF (SPIT)

• RFC 5038– “The Session Initiation Protocol (SIP) and SPAM”

• draft-niccolini-sipping-spitstop– Signalling TO Prevent SPIT (SPITSTOP) Reference Scenario

• draft-niccolini-sipping-feedback-spit– SIP Extensions for SPIT identification

• draft-jung-sipping-authentication-spit– Authentication between the Inbound Proxy and the UAS for

Protecting SPIT in the Session Initiation Protocol (SIP)• draft-schwartz-sipping-spit-saml

– SPAM for Internet Telephony (SPIT) Prevention using the SecurityAssertion Markup Language (SAML)

• draft-froment-sipping-spit-authz-policies– Authorization Policies for Preventing SPIT


UC in the ITU (multimedia SPAM)• The ITU is working on the thread Countering spam by technical means in the ITU-T

Study Group 17 - Question 17/17 (Study Period 2005-2008).• X.ocsip

– Overview of countering SPAM for IP multimedia applicationThis Recommendation specifies basic concepts, characteristics, and effects of Spam inIP multimedia applications such as IP Telephony, instant messaging, multimediaconference, etc. It provides technical issues, requirements for technical solutions, andapplicability of countering mechanism of email spam into IP multimedia spam. It providesbasis and guideline for developing further technical solutions on countering Spam.

• X.fcsip– Technical Framework of Countering IP Multimedia SPAM

This Recommendation will specify general architecture of countering spam system on IPmultimedia applications such as IP Telephony, instant messaging, multimediaconference, etc. It will provide functional blocks of necessary network entities to counterspam and their functionalities, and describe interfaces among the entities. To buildsecure session against spam attack, User Terminals and Edge Service Entities such asproxy server or application servers will be extended to have spam control functions. Wewill also show interfaces between these extended peer entities, and interfaces with othernetwork entities which can involve for countering spam.

• X.1231 (former X.csreq)– Requirement on countering SPAM

Requirements on countering spam are clarified in this recommendation. There are manytypes of spam, such as email spam, Mobile messaging spam and IP multimedia spam.Various types of spam may have both common and specific requirements on counteringit. For one type of spam, the requirement in different entities should also be clarified.


UC in 3GPP (SMS/MMS SPAM)• ETSI TR 141 031 V6.0.0 / ETSI TS 122 031 V6.0.0. / ETSI TS 123 031 V6.0.0

Fraud Information Gathering System (FIGS)– FIGS provides the means for the HPLMN to monitor a defined set of

subscriber activities.

• 3GPP TR – XXX XXXProtection against SMS, MMS and IMS SPAM; Study of Different SPAMProtection Mechanisms– This TR analyzes existing and new mechanisms to limit the effects

of SPAM to following services: SMS, MMS, IMSmessaging/presence/call and also email messages.� Investigation based on the 3GPP architecture regarding SMS/MMS/IM SPAM

were done� Potential solution to counter this threat were analyzed and defense mechanisms

were proposed

• 3GPP TR – XXX XXXPUCI - Prevention of Unsolicited Communication in IMS– This specification study will give the requirements and recommendation

how to prevent UC in the IMS part of the NGN


UC in OMA

• OMA– OMA has drafted a set of requirements and architecture for

Categorization Based Content Screening (CBCS) suggesting amongother things usage of ICAP protocol to transfer contentcategorization information. Content Screening is defined as the actof blocking, allowing or amending content, thereby, it also includesmalware.

– The current OMA work can be found in the following specifications:� Categorization Based Content Screening Framework Requirements, Candidate

Version 1.0 – 11 July 2006 (a newer one may already exist), Open MobileAlliance OMA-RD-CBCS-V1_0-20060711-CThe document describes Use Cases for categorization based content screeningand high level requirements on the functionality of such a system.

� Categorization-based Content Screening Framework Architecture, Draft Version1.0 – 28 Aug 2006, Open Mobile Alliance OMA-AD-CBCS-V1_0-20060828-DThe document presents an architectural model for a two-tier solution of a CBCSEnabler. The CBCS Enabler evaluates and/or enforces Screening Rules.


UC in TISPAN (unsolicited communication)

• ETSI TS 183 016 - MCID (Malicious call identification)– This service for blacklisting

• ETSI TS 186 006-1 - OIR (Originating Identification Restriction )– The service offers personalized lists

• ETSI EN 300 798 - ACR (Anonymous Communication Rejection)– Unknown caller blocking

• ETSI TS 183 011- ICB (Incoming Communication Barring)– The service offers personalized black / whitelisting

• ETSI TR 187 009 – Feasibility study of preventing unsolicited communication in the NGN– This report deals with the feasibility of counteracting the occurrence of Unsolicited

Communications (UC) in the NGN. It has the form of a TVRA and quantifies thelikelihood and impact of UC in the NGN.

• TS xxx xxx - PUC (Prevention of unsolicited communication in the NGN)– This specification study will give the requirements and recommendation how

to prevent UC in the NGN


TISPAN – best coordination place

UE P-CSCF

RA

CS

NA

SS

UPSF ASIBCF

IBGF

Ut

Sh

CxI/S-CSCF

Mw

ISCMx

SBC

NNI

UEHomeGW

Userprofiles

AS

TISPAN 3GPP OMAITU-TIETF

Caller (SPITer) Callee (Bob)

Core networkAccessnetwork

Accessnetwork

protocols framework PUC PUCI CBCS


AOB

Question & Answers

Documents

Unsolicited Communication in the NGN - Directory … 1 ETSI Security Workshop Unsolicited Communication in the NGN Overview of Status and Activities in different SDOs