Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
SIP-based VoIP Traffic Behavior Profiling and Its Applications

SIP-based VoIP Traffic Behavior Profiling and Its Applications

Ratings: (0)|Views: 13|Likes:
Published by StopSpyingOnMe
SIP-based VoIP Traffic Behavior Profiling and Its Applications Narus
SIP-based VoIP Traffic Behavior Profiling and Its Applications Narus

More info:

Published by: StopSpyingOnMe on Aug 21, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

09/07/2013

pdf

text

original

 
SIP-based VoIP Traffic Behavior Profiling and Its Applications
Hun Jeong Kang, Zhi-Li ZhangUniversity of MinnesotaEmail:
{
hkang, zhzhang
}
@cs.umn.eduSupranamaya Ranjan, and Antonio NucciNARUSEmail:
{
soups, anucci
}
@narus.com
Abstract
With the widespread adoption of SIP-based VoIP, under-standing the characteristics of SIP traffic behavior is crit-ical to problem diagnosis and security protection of VoIPservices – two key aspects of providing dependable VoIPservices. In this paper we propose a general methodol-ogy for profiling SIP-based VoIP traffic behavior at sev-eral levels: SIP server host, server entity (e.g., registrar and call proxy) and individual user levels – to derive “nor-mal” behavior profiles. Using SIP traffic traces captured ina production VoIP network, we illustrate the characteristicsof SIP-based VoIP traffic behavior in an operational envi-ronment and demonstrate the effectiveness of our general profiling methodology. Based upon the profiling method-ology, we develop a simple and yet effective entropy-based anomaly detection algorithm for detecting potential secu-rity attacks as well as performance problems. We demon-strate the efficacy of our algorithm in detecting potentialVoIP attacks through testbed experimentation.
1 Introduction
Voice over IP (VoIP) allows users to make phone callsover the Internet, or any other IP network, using the packetswitched network as a transmission medium rather thanthe traditional circuit transmissions of the Public SwitchedTelephone Network (PSTN). VoIP has come a long waysince it first rudimentary applications provided erratic yetfree phone calls over the unmanaged Internet. VoIP tech-nology has reached a point of being comparable in termsof grade voice quality with traditional PSTN yet consum-ing only a fraction of the bandwidth required by TDM net-works. The maturity of VoIP standards and quality of ser-vice (QoS) on IP networks opens up new possibilities forcarrier applications. Consolidation of voice and data on onenetwork maximizes network efficiency, streamlines the net-work architecture, reduce capital and operational costs, andopens up new service opportunities. At the same time, VoIPenablesnewmultimediaserviceopportunities, suchasWeb-enabled multimedia conferencing, unified messaging, etc,while being much cheaper.VoIP offers compelling advantages but it also presents asecurityparadox. TheveryopennessandubiquitythatmakeIP networks such powerful infrastructures also make thema liability. Risks include Denial of Service (DoS), ServiceTheft, Unauthorized Call Monitoring, Call Routing Manip-ulation, Identity Theft and Impersonation, among others.Not only does VoIP inherit all data security risks, but it in-troduces new vehicles for threats related to the plethora of new emerging VoIP protocols that have yet to undergo de-tailed security analysis and scrutiny.But just how serious are the threats posed to VoIP [4].Recently, there have been a string of attacks against ei-ther the VoIP infrastructure or end users. In one such inci-dent, early June of 2006, two men were arrested for fraud-ulently routing approximately
500
,
000
calls illegally overthe VoIP network belonging to Net2Phone, a Newark, N.J.,VoIP provider. Fifteen Internet phone companies were re-portedly as the victims of this attack. More recently, ISSposted a report about a Denial-of-Service vulnerability inthe IAX2 implementation of Asterisk, an open source soft-ware PBX. This vulnerability relates to the amount of timethat a pending (but not yet authenticated) call is allowed toexist in memory on the server. New terms start to be coinedover time just for VoIP attacks; “Vishing”, is now used forphishingattacksusingVoIPtechnology, or“Spit”, nowusedfor spam over VoIP.Hence it is imperative for service providers to widelydeploy scalable monitoring systems with powerful toolsacross their entire infrastructures such to robustly shieldtheir VoIP infrastructure and protect their service, therebyproviding
dependable
VoIP services. In this paper we pro-pose a SIP traffic behavior profiling methodology, with theobjective to identify anomalies and help service providersto accurately diagnose problems on-fly and promptly de-tect and trace-back on-going attacks on critical VoIP ser-vice (and their infrastructure). We propose a
multi-level
,
 progressively refined 
methodology that characterizes VoIPservice activity in real-time by extracting and profiling alarge variety of traffic features and metrics at three differ-1
 
ent levels: (i)
server 
, e.g. broad-view of their behavior bymonitoring and keeping statistics related to only the mes-sage types (request vs response); (ii)
entity
, e.g. coarse-view of the servers activity by separating their logical rolesinto
registrar 
and
call proxy
; and (iii)
individual users
, e.g.narrow-view of individual user activities, like typical av-erage duration and length of the calls, number of calls re-ceived and made, etc. As a consequence, our methodologyallowsustobalancethespeedofprofiling, theresourcecon-sumption, the desired sophistication of behavior character-istics, andfinallythelevelofsecuritytobeoffered, basedonthe specific objectives and needs of the VoIP operator. Builtupon the SIP traffic behavior profiling methodology, we de-velop a simple and yet effective entropy-based anomaly de-tection algorithm for detecting potential security attacks aswell as performance problems. We demonstrate the efficacyof our algorithm in detecting potential VoIP attacks throughtestbed experimentation.The remainder of this paper is structured as follows. InSection 2 we introduce some basic concepts of the SIP-based service, we discuss how challenging is to monitorand profile the service and introduce the data sets used inthis paper to identify meaningfully VoIP traffic features tobe profiled. In Section 3 we present in great details ourmethodology. First we introduce a new algorithm to auto-matically discover SIP servers, and breaks down their log-ical functionality, e.g. registrars and call proxies. Secondwe discuss at very high-level which traffic features shouldbe monitored at the
server 
,
entity
and
individual user 
levelsin order to gain a complete view of the VoIP traffic activ-ity. Third we introduce a new algorithm based on Infor-mation Entropy that profiles the chosen metrics over timeand generates alerts while any of the features diverges fromits historical trend. Section 4 analyzes the traffic featuresdiscussed in Section 3 while using real packet traces col-lected from a wireless VoIP service provider. This sectionhighlights some preliminary interesting findings that vali-dates the overall approach. Section 5 describes three differ-ent VoIP attacks generated in a controlled lab environmentand presents the outcome results of applying our methodol-ogy. Section 7 summarizes our findings and concludes thepaper.
2 Background and Data Sets
We first provide a quick overview of SIP-based IP tele-phony. We then briefly touch on the challenges in profilingSIP traffic behaviors based on
passive packet monitoring
,and describe the SIP data sets used in our study.
2.1 SIP-based VoIP Service
The session initiation protocol (SIP) [9] is the Internetstandard signaling protocol for setting up, controlling, andterminating VoIP sessions
1
. SIP-based VoIP services re-quire
infrastructure
support from entities such as SIP regis-trars, call proxies, and so forth (see Fig. 1) – we collectivelyrefer to these entities as
SIP servers
. A SIP registrar asso-ciates SIP users (e.g., names or identities called
SIP URIs
)with their current locations (e.g., IP addresses). A SIP callproxyassistsusersinestablishingcalls(called
dialogs
intheSIP jargon) by handling and forwarding signaling messagesamong users (and other SIP servers). In practice, a physicalhost (SIP server) may assume multiple logical roles, e.g.,functioning both as registrars and call proxies.
Figure 1. SIP servers and clients
SIPisatext-based
request
-
response
protocol, withsyntax very similar to HTTP. SIP messages are of type ei-ther
request
or
response
. The
method
field is usedto distinguish between different SIP operations. The mostcommon
methods
include
REGISTER
(for user regis-tration),
INVITE
,
ACK
,
BYE
,
CANCEL
(these four usedfor call set-up or tear-down),
SUBSCRIBE
, and
NOTIFY
(for event notification).
Response
messages contain a
response code
informing the results of the requestedoperations (e.g.,
200 OK
). The
FROM
and
TO
fields in anSIP message contain respectively the SIP URIs of the userwhere a
request
message is originated from (e.g., thecaller of a call) or destined to (e.g., the callee of a call). Inthe case of a
REGISTER
message, both
FROM
and
TO
typi-callycontaintheSIPURIoftheuserwherethe
request
isoriginated. Other important fields include
VIA
and variousidentifiers and tags to string together various transactionsand dialogs. The reader is referred to [9] for details.
2.2 Problem Discussion and Data Sets
In this paper, we focus on characterizing and profil-ing SIP-based VoIP traffic behavior by using
passive traf- fic monitoring
, with the objective to identify anomalies to
1
In addition to IP telephony, it can also be used for teleconferencing,presence, event notification, instant messaging, and other multimedia ap-plications.
 
help diagnose problems and detect potential attacks on crit-ical VoIP services (and their infrastructure). We assumethatpassivepacketmonitoringandcapturingdevicesarede-ployed in the underlying network hosting VoIP services. Inaddition to the standard layer-3 (IP) and layer-4 (TCP/UDP)header information, portion of layer-7 payload containingappropriate application protocol (SIP) fields are also cap-tured. The captured packet header and payload informationis then processed and parsed for our analysis and profil-ing. Unlike the layer 3/4 header fields which generally havewell-defined and
limited 
semantics, the layer-7 applicationprotocol such as SIP has a variety of fields, with
rich
se-mantics that are often context-sensitive and sometimes evenimplementation-specific. For example, with the SIP proto-col itself, the meaning of the same fields may depend on themethod used. Hence a major challenge in performing layer-7 protocol analysis and behavior profiling is to determinehow to judiciously incorporate application-specific seman-tics or “domain knowledge” to select appropriate set of keyfeatures to capture the essential behavior characteristics of the application in question. In the next section we presentsuch a general methodology for characterizing and profilingSIP-based VoIP traffic behavior.Our profiling methodology is motivated and substanti-ated by in-depth analysis of SIP traffic traces captured inan operational network of a commercial wireless VoIP ser-vice provider. The results reported in this paper use threeSIP traces from this network, referred to as
Trace I (13:55-14:30)
,
Trace II (19:00-19:40)
and
Trace III (19:55-20:30)
,respectively (the numbers within the parentheses indicatethe start and end time of the traces). They are of about 40minutes or so long, captured between 13:00 h and 21:00 hwithin a single day.
3 General Methodology
In this section, we present a multi-level profilingmethodology for characterizing SIP traffic behavior usinglayer-3 to layer-7 protocol information obtained from
pas-sivenetworkmonitoring
. InordertocharacterizeandprofileSIP server behaviors by using passively collected SIP traffictraces, we need to identify the IP addresses associated withSIP servers. We first introduce a simple heuristic for iden-tifying the IP addresses associated with SIP servers (bothSIP registrars and call proxies) based on passive monitoringof SIP traffic. We then present a general methodology forcharacterizingandprofilingSIPserverbehaviorsatmultiplelevels.
3.1 Discovering SIP Servers
The key observation behind our heuristics is based onthe role of SIP servers in SIP-based VoIP communications:typically users must register with SIP registrars; and users’call signaling must get through SIP call proxies (see Fig. 1).Hence the IP address associated an SIP server will consis-tently see a large number of SIP messages going throughit (i.e., with the said IP address as either the source ordestination IP addresses); furthermore, we will also see alarge number of distinct
FROM
and
TO
fields in the appro-priate SIP messages (e.g.,
INVITE
,
REGISTER
) associ-ated with this IP address. The baseline algorithm for SIPcall proxy discovery is given in Algorithm 1 examining theSIP
INVITE
messages. By examining the SIP
REGISTER
messages, we have a similar algorithm for SIP registrar dis-covery.
Algorithm 1
Baseline Algorithm for SIP Call Proxy Dis-covery
1:
Parameters: message set
, threshold
α
;
2:
Initialization:
IPSet
:=
;
ProxyIP 
:=
;
3:
for each
m
do
4:
if 
m
.
method
==
INVITE
then
5:
x
=
m
.
sourceIP
;
y
=
m
.
destinationIP
;
6:
from
=
m
.
FROM
;
to
=
m
.
TO
;
7:
if 
x
IPSet
then
8:
x.Out
FROM
=
{
from
}
;
x.Out
TO
=
{
to
}
;
9:
x.In
FROM
=
;
x.In
TO
=
;
10:
else
11:
x.Out
FROM
=
x.Out
FROM
∪ {
from
}
;
12:
x.Out
TO
=
x.Out
TO
∪ {
to
}
;
13:
end if 
14:
if 
[
|
x.In
FROM
|
,
|
x.In
TO
|
,
|
x.Out
FROM
|
,
|
x.Out
TO
|
]
>
[
α,α,α,α
]
then
15:
ProxyIP 
=
ProxyIP 
∪ {
x
}
16:
end if 
17:
if 
y
IPSet
then
18:
y.In
FROM
=
{
from
}
;
x.In
TO
=
{
to
}
;
19:
y.Out
FROM
=
;
y.Out
TO
=
;
20:
else
21:
y.In
FROM
=
y.Out
FROM
∪ {
from
}
;
22:
y.In
TO
=
y.In
TO
∪ {
to
}
;
23:
end if 
24:
if 
[
|
y.In
FROM
|
,
|
y.In
TO
|
,
|
y.Out
FROM
|
,
|
y.Out
TO
|
]
>
[
α,α,α,α
]
then
25:
ProxyIP 
=
ProxyIP 
∪ {
y
}
26:
end if 
27:
end if 
28:
end for
InAlgorithm1, foreachIPaddress
a
intheSIPmessages(either as the source or destination IP) we maintain fourrecords,
a.In
FROM
,
a.In
TO
,
a.Out
FROM
and
a.Out
TO
, whichmaintain, respectively, the set of unique users (or rathertheir URIs) seen in the
FROM
and
TO
fields of the SIP
INVITE
messages
received 
(In) by or
sent 
(Out) from
a
.If the number of distinct users in each of the four records

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->