Enabling Secure IP Telephony in Enterprise Networks By … · 2005-03-23 · Enabling Secure IP Telephony in Enterprise Networks By BRENNEN EMERICK REYNOLDS B.S. (University of California,

Enabling Secure IP Telephony in Enterprise Networks

By

BRENNENEMERICK REYNOLDSB.S.(University of California,Davis) 2001

THESIS

Submittedin partialsatisfactionof therequirementsfor thedegreeof

MASTERSOFSCIENCE

in

ComputerEngineering

in the

OFFICEOF GRADUATE STUDIES

of the

UNIVERSITY OF CALIFORNIA

DAVIS

Approved:

Committeein charge

2002

–i–

Enabling Secure IP Telephony in Enterprise Networks

Copyright 2002by

BrennenEmerickReynolds

Dedicatedto Popfor hisunselfishgift of knowledgeandwisdom.

–iii–

Acknowledgments

I would like to thankthe membersof my thesiscommittee,Dr. Matt Bishop,Dr. Chen-

NeeChuah,andespeciallyDr. Dipak Ghosal,for their invaluableguidanceandsupport

throughout the entireprocessof researchingandwriting this thesis. I would alsolike to

thankDr. S.Felix Wu for his commentsonearlydraftsof thematerial.

–iv–

Contents

List of Figures vii

List of Tables viii

1 Introduction 11.1 A New Paradigmof Services& Applications . . . . . . . . . . . . . . . . 11.2 IP Telephony in ConvergedNetworks . . . . . . . . . . . . . . . . . . . . 21.3 SecurityIssuesin aConvergedNetwork . . . . . . . . . . . . . . . . . . . 31.4 Key Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 ThesisOrganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 IP Telephony Over Converged Networks 72.1 ConvergedNetwork Architecture . . . . . . . . . . . . . . . . . . . . . . . 72.2 IP Telephony Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 SessionInitiationProtocol . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Call ControlUsingSessionDescriptionProtocol . . . . . . . . . . 122.2.3 MediaTransportUsingReal-TimeProtocol . . . . . . . . . . . . . 142.2.4 SIPCall Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 STEM - Secure Telephony Enabled Middlebox 193.1 PreviousWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 ApplicationLayerProxies . . . . . . . . . . . . . . . . . . . . . . 203.1.2 LayeredFirewall Architectures. . . . . . . . . . . . . . . . . . . . 223.1.3 IETF Initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 ArchitectureComponents. . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.1 SecurityManager. . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3 Media/SignalGateway, SIPProxy& SIPRegistrar . . . . . . . . . 28

3.3 Inter-DeviceCommunication . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 ExampleCall Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 IncomingNet-to-NetCalls . . . . . . . . . . . . . . . . . . . . . . 293.4.2 OutgoingNet-to-NetCalls . . . . . . . . . . . . . . . . . . . . . . 323.4.3 PSTN-to-NetCalls . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.4 Net-to-PSTN Calls . . . . . . . . . . . . . . . . . . . . . . . . . . 35

–v–

3.5 ImplementingaPrototypeof STEM . . . . . . . . . . . . . . . . . . . . . 373.5.1 BuildingaDynamicFirewall . . . . . . . . . . . . . . . . . . . . . 373.5.2 IncorporatingtheSecurityManager . . . . . . . . . . . . . . . . . 42

4 Vulnerabilities in Converged Networks 434.1 InformationGathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 ConnectionHijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 Denialof Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Secure IP Telephony using Multi-layered Protection Framework 485.1 PreviousWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2 Property-OrientedVulnerability Analysisfor IP Telephony . . . . . . . . . 50

5.2.1 AccessControl to UsetheIP Telephony Services . . . . . . . . . . 505.2.2 Integrity andAuthenticityof theIP Telephony SignalingMessages. 515.2.3 ResourceFairnessandAvailability in Providing IP Telephony Ser-

vices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.3 Sensorsfor DetectingDoSAttacks . . . . . . . . . . . . . . . . . . . . . . 53

5.3.1 ApplicationLayerAttackSensor(ALAS) . . . . . . . . . . . . . . 545.3.2 TransportLayerAttackSensor(TLAS) . . . . . . . . . . . . . . . 555.3.3 ALAS for PSTNOriginatedAttacks . . . . . . . . . . . . . . . . . 565.3.4 RTP StreamAttackSensor(RSAS) . . . . . . . . . . . . . . . . . 57

5.4 Designof ALAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.4.1 DetectionAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . 585.4.2 RecoveryAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.5 QuantitativeAnalysisof ALAS . . . . . . . . . . . . . . . . . . . . . . . . 605.5.1 DoSAttackModels. . . . . . . . . . . . . . . . . . . . . . . . . . 615.5.2 EnterpriseUserModel . . . . . . . . . . . . . . . . . . . . . . . . 625.5.3 Simulation Parameters. . . . . . . . . . . . . . . . . . . . . . . . 625.5.4 ExperimentalResults. . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Summary 666.1 FutureWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A List of Publications & Presentations 68A.1 Publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A.2 Presentations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Bibliography 70

–vi–

List of Figures

2.1 IP Telephony EnabledEnterpriseNetwork . . . . . . . . . . . . . . . . . . 72.2 SampleSIPINVITE Message . . . . . . . . . . . . . . . . . . . . . . . . 132.3 RTPPacketLayout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 SIPDirectCall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 SIPRedirectCall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 SIPProxyCall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7 SIPPSTNCall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 DecomposedFirewall Architecture. . . . . . . . . . . . . . . . . . . . . . 213.2 AdaptionLayeredFirewall Architecture . . . . . . . . . . . . . . . . . . . 233.3 SecureTelephony EnabledMiddleboxArchitecture . . . . . . . . . . . . . 243.4 InternalLayoutof STEMFirewall . . . . . . . . . . . . . . . . . . . . . . 263.5 IncomingNet-to-NetCall Flows - Part 1 . . . . . . . . . . . . . . . . . . . 303.6 IncomingNet-to-NetCall Flows - Part 2 . . . . . . . . . . . . . . . . . . . 313.7 OutgoingNet-to-NetCall Flows . . . . . . . . . . . . . . . . . . . . . . . 333.8 PSTN-to-NetCall Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.9 Net-to-PSTNCall Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.10 NetfilterHookLayout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1 ALAS placedbehindtheSIPProxy. . . . . . . . . . . . . . . . . . . . . . 555.2 DetectingPSTNBasedDoSAttacks . . . . . . . . . . . . . . . . . . . . . 575.3 ALAS Placedwithin theDMZ . . . . . . . . . . . . . . . . . . . . . . . . 615.4 IndividualURI DetectionusingLimited DoS( �� and� �� ) . . . 635.5 AggregateLevel Detection( �� and� �� ) . . . . . . . . . . . . . 64

–vii–

List of Tables

2.1 SIPRequestMethods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 SIPResponseCodeCategories . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1 EnterpriseCall Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2 DoSAttackDetectionTime . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3 RecoveryTime for Limited DoSonLow VolumeURI . . . . . . . . . . . . 65

–viii–

1

Chapter 1

Introduction

1.1 A New Paradigm of Services & Applications

Over the pasttwo decades,network traffic hasevolved from short text messagesto

high volumemultimediadriven content. With the rapid introduction of new applications

andservicesinto the global networks, therearenew requirements in the operationof the

network. For example,new real-timeapplicationsdemandamuchhigherqualityof service

(QoS)thanexisting applicationssuchastransferring electronicmail.

A key outcomeof this is an increasein the complexity of the network infrastructure.

However, thefundamentaloperationof thesedeviceshasnotchanged.Enterprisenetworks

of todayareconnectedtogetherthrough a large numberof staticdeviceswhich include

firewalls, intrusiondetectionsystems,andnetwork addresstranslationdevices. Thesede-

vicesarecollectively referredto asmiddleboxes.Middleboxeswereoriginally designedto

operatewith traffic thatcanbespecifiedusingasimplestaticsetof rules.They arecapable

of handlingtheapplicationscurrentlydeployedwithin enterprises,but thatis changing.

New applicationsarebeingintroducedin corporatenetworks.Thefunctionality of these

new applicationsis muchmoredynamicthanexistingservices.Themostwidely deployed

dynamicapplicationsthusfar have beenInternetProtocol(IP) Telephony andvideocon-

2

ferencing.While thesenew applicationsoffer servicesnot previously availableover data

networks, problems have stemmedfrom the dynamicnatureof the underlyingprotocols.

Dynamicapplicationsdo not operateusingthe well-known port structurethat traditional

client-server serviceshave used.1 Eachsessionof a dynamicapplicationconsistsof mul-

tiple datastreamswith only thefirst controlstreamconnectingto awell-known porton the

remoteterminal. Theadditional datastreams,usedfor audioandvideodatain IP telephony

andvideoconferencing,aresentbetweenarbitraryportsnegotiatedby theendpointsusing

theinitial connection.

Creatingrule setsto allow traffic from dynamicapplicationsto passthroughstaticnet-

work middleboxesis a significantproblem. Generalizingfrom a singlesessionto an en-

terpriselevel only increasesthe complexity of rule creation. Becauseeachsessioncan

theoreticallyuseany of the64k availableports,theonly typeof traditional rulesthatcan

beusedfor dynamicapplicationsis to allow all traffic to pass.Implementing this typeof

rule set rendersfiltering devices including firewalls useless.Thus, this is not a practical

solutionfor enterpriseswishingto deploy dynamicapplications.

1.2 IP Telephony in Converged Networks

An importantdynamicapplicationthatis rapidly gainingadoptionin theindustryis IP

telephony. A driving force behindthe successof IP telephony is it allows enterprisesto

offer servicesand levels of integration not possiblewith standardtelephony systems.A

simpleexampleis theadditionof Click-to-Call serviceson productsupportpagesto allow

customersto automatically contactan enterprisesupportstaff [1]. Anotherbenefitof IP

telephony is the reductionin overall operatingexpenses.With a completedeploymentof

IP telephony, only oneenterprisewide network mustbeprovisionedandmaintained.The

maintenancecostsof adatanetwork aremuchlessthanacircuit switchednetwork because�Servicessuchasemail, file transferandthe World Wide Web all operateat a standardport number or

well-known port number.

3

1) statisticalmultiplexing gain in thedatanetwork and2) lesscomplex thancircuit based

networks. This, coupledwith the improved bandwidthefficiency of the voice encoding

algorithmsusedin IP telephony, dramaticallyreducesthepercall costacrosstheenterprise.

IP telephony notonly removestheneedfor two networkswithin anenterprise,it alsoal-

lowstheinterconnectionof two globalnetworks.A full IP telephony deploymentwithin an

enterpriseincludesconnectionsto theInternetandthePublicSwitchedTelephoneNetwork

(PSTN).As aresult,theenterprise’snetwork actsasabridgeandcontrolpointbetweenthe

two networks. The interconnection of thesetwo networkswill eventuallyallow terminals

oneithernetwork to utili zeandaccess resourcesandinformationcontainedin both.

IP telephony servicescanbedeployedusingoneof two differentprotocols.TheInternet

EngineeringTaskForce(IETF) hasdevelopedaplaintext protocolcalledSessionInitiation

Protocol(SIP)[23] basedon thestructureof theHypertext TransferProtocol(HTTP) [18].

TheInternational TelecommunicationUnion (ITU) developedH.323[31] which inherited

thestructureandbasicfunctionality from theSignalingSystem7 (SS7)[47] protocolused

within the PSTN.The two protocolsarenot directly compatible but provide comparable

features.H.323wasdevelopedfirst andcurrentlyhasa largerpieceof themarketsharebut

recentlySIPhasbeengainingmomentum[58].

As with any new technologytherearemany different issuesthat mustbe addressed.

Enterprisesdeploying IP telephony musttacklethemanagementof new network resources,

guaranteeahigh level of qualityof service(QoS)within thenetwork, andensurethatall IP

telephony devicesareinteroperable.Eachof theseissuesmustbeproperlyaddressedfor

anIP telephony deploymentto besuccessful.

1.3 Security Issues in a Converged Network

The convergenceof the Internetand the PSTN is either an exciting or a very scary

proposition dependingon one’s perspective. From an information accessibilityandinte-

4

gratedservicesviewpoint, the possibilitiescreatedby the interconnectionis almostun-

limited. However, the securityimplications surrounding the convergenceare extremely

significant.Bothnetworkshaveuniquevulnerabilities andthreatmodels.By interconnect-

ing the two, new threatmodelsarecreatedwhich not only encompassthe two individual

modelsbut alsonew crossnetwork vulnerabilitiesandattacks.

Thesecurityramificationsof two globalnetworksconverging is not theonly elementof

IP telephony wheresecuritymustbeconsidered.Both IP telephony protocolsarerelatively

new andstill undergoing development.As a result,they have not beencompletelyscruti-

nizedandexaminedfor vulnerabilities. Furthermore, implementationsusingtheprotocols

arealsoverynew andhavenotundergoneexhaustive testing.

Onesignificantdifferencebetweentraditional telephony servicein the PSTNandIP

telephony is the mannerin which dataand control information are transported. In the

PSTNthecontrolanddataareseparatedby differentlogical channels.This resultsin end

terminalsbeing unableto accessand manipulatethe control information. IP telephony

removesthe separationandincorporatesboth intelligenceandcontrol mechanismsin the

end terminals. Furthermore,both the control and datainformation are now transmitted

over a network maintained by numerousindependentandsometimescompetingnetwork

andserviceproviders.Theopenarchitectureof theInternetgreatlyincreasestheability of

unauthorizedpartiesto collectand/ormodify informationstreams.

Ensuringthe integrity of thecall is a major concernthatmustbeaddressedbeforeIP

telephony canbewidely deployed. In additionto theuseof asingletransportmedium,use

of theInternetProtocol[27] astheunderlying transportprotocolresultsin a largernumber

of vulnerabilitiesandweaknesses.

5

1.4 Key Contributions

The overall objective of this thesisis to allow dynamicapplications, specificallyIP

telephony, to be deployed securelywithin an enterprise.To achieve this objective, three

differentissuesareaddressedin this thesis.

� TheSecureTelephony EnabledMiddlebox(STEM)architectureprovidesthefounda-

tion for securelydeploying IP telephony services.It includesasecurityenforcemententity

andanintelligentfirewall capableof handlingdynamicapplicationsessions.

� A classificationof vulnerabilities within STEM and the IP telephony protocolsis

carriedout. Thelist categorizestheattacksby typeandanalyzestheir impact.

� The Simple IP Telephony usingMulti-l ayeredProtection(STUMP) framework in-

cludesa property-orientedvulnerability analysisfor IP telephony. Four differentsensors

detectandcontrolmostflood basedDoSattackstargetingan IP telephony enabledenter-

prisenetwork.

1.5 Thesis Organization

The remainderof this thesisis organized asfollows. Chapter2 expandson the inter-

workings of the layout of converged networks, the SIP protocol, and typical call setup

scenarios.Chapter3 describesa modifiedconvergednetwork architecturecalledSecure

Telephony EnabledMiddlebox (STEM). Detailsof the architecturalcomponentsandde-

viceinteractionarediscussedin thischapter. Thechapteralsoexamineshow severaltypical

call scenariosarehandledby the new architecture.The chapterconcludeswith a discus-

sionof aneffort to implementaprototypeof theSTEMarchitecture.Chapter4 enumerates

themajornetwork vulnerabilitieswithin aconvergednetwork andin IP telephony services.

Chapter5 introducesthe SecureIP Telephony usingMulti-layeredProtection(STUMP)

framework. TheSTUMPframework reducesthe impactof a largenumberof thevulner-

abilities outlined in Chapter4 usingboth new andexisting protectionmechanisms.The

6

chapteralsoincludesquantitative analysisof anattacksensorsdevelopedto handleflood

baseddenialof service(DoS)attacks.A summaryof thiswork andconcludingremarksare

givenin Chapter6.

7

Chapter 2

IP Telephony Over Converged Networks

2.1 Converged Network Architecture

A typicalenterprisenetwork consistsof two sections:1) theinternalnetwork and2) the

de-militarizedzone(DMZ). TheDMZ is connectedto thepublic Internetthrough anexter-

nal firewall andcontainsvariousserversthatneedto beaccessedfrom externallocations.

This includesweb,mail, anddomainnameservice(DNS) servers. The internalnetwork

is connectedto theDMZ by anotherfirewall. In somearchitectures,the two firewalls are

replacedby asinglefirewall with threenetwork interfaces[12].

Deploying complex new servicescanrequirebothadditional devicesto beaddedand

Enterprise DMZ

SIP �

Redirect Proxy

SIP �

Registrar / Location Server �

Web Server �DNS

Server �

Edge Router

External Firewall

Internal Firewall

Softphone � IP Phone

Enterprise LAN

Authentication Server �

PSTN

Media / Signal �

Gateway �

Internet

Figure2.1: IP Telephony EnabledEnterpriseNetwork

8

existing elementsto bemodified. IP telephony is no exception.An exampleIP telephony

enabledenterprisenetwork is shown in Figure 2.1. Additional componentsthat are re-

quiredincludea SIPProxyanda Registrar/LocationServer, anda Media/SignalGateway

to connectto thePSTN.

TheSIPProxyserver [46] (or H.323Gatekeeper[21]) is placedin theenterpriseDMZ.

All IP telephony signalingandcontrol traffic is routedthroughtheproxy while themedia

streamsbypasstheproxyandareexchangeddirectlybetweentheendterminals.Theproxy

server cansupportadditionalfeaturessuchaslists of addressesusedfor Spam.TheSpam

lists could include both individual client lists as well as enterprisewide lists. The SIP

Registrar/LocationServer (RLS) is also locatedwithin the enterpriseDMZ. The RLS’s

main function is maintaining the location(IP address)of enduserswithin the enterprise.

TheRLSmustalsocommunicatewith otherRLSsto determineoptimal call pathselection

for telephony routingover IP (TRIP) [45].

TheMedia/SignalGateway(MSG) is acompletenetwork stackproxythatconnectsthe

internalLAN to thePSTN.TheMSG consistsof voiceportsboundto voicetrunkson the

PSTNsideandan Ethernetconnectionto the internalLAN. Additionally, it may include

a pair of SS7signalinglinks to a SignalTransferPoints(STPs). The gateway provides

controlanddatamessageconversionbetweenthetwo networks.

In additionto the introduction of new devicesin theenterprisenetwork, certainexist-

ing network elementsmustbe modified. The staticfirewalls mustbe replacedwith new

dynamicfirewalls capableof parsingall layersof the network stackor applicationlayer

proxiesto handlethedynamicapplicationstraffic.

To enablecrossnetwork calls(PSTN-to-NetandNet-to-PSTN),theDNS servicemust

be extended. Eachtelephony terminal must be assignedan E.164number, a.k.aphone

number, in asimilar fashionto PSTNterminals.TheDNSserversmustthenimplementthe

ENUM protocol[17]. ENUM usestheNAPTR DNS ResourceRecord[14] type to store

a mappingof E.164numberto a globally uniqueDNS name.All ENUM namesbelongto

9

thee164.arpadomain.While ENUM is requiredfor PSTN-to-Netcalls,it canalsobeused

for Net-to-Netcalls.

2.2 IP Telephony Protocols

Over thepastfour years,two protocols have beendevelopedto supportIP telephony;

SessionInitiation Protocol(SIP) andH.323. Both protocols provide a similar setof ser-

vicesbut arevery differentarchitecturally. SIP, developedby the IETF, is basedon the

Hypertext TransferProtocol(HTTP) andis a text basedwhich usesthe SessionDescrip-

tion Protocol(SDP)[22], anothertext basedprotocol,for channelestablishmentandcon-

figuration. H.323, developedby the ITU, is an umbrellanamegiven to a large suiteof

protocols. Within the H.323 protocol suite [21] are H.245 for call control, H.225.0for

connectionestablishment,H.235for securityandH.332for conferencecalls. All thepro-

tocolsin the suiteutili ze ASN.1 andpacked encodingrulesfor generatingmessages.To

manipulatethesemessages,specialcode-generatorsmustbe used. Both H.323 andSIP

utilize theReal-Time Protocol(RTP) [51] to transferthemultimediadata.This meansthe

choiceof call controlprotocol doesnot influencethequalityof serviceof acall [53]. Given

thatH.323is a morecomplex protocolto decodeandexamine,this work is basedon SIP.

However, thesolutionsoutlinedareapplicableto aH.323environment.

2.2.1 Session Initiation Protocol

The SessionInitiation Protocol[23] is an ASCII basedclient-server protocol (server

sidebindsto port 5060)thatuseseithertheTransmissionControlProtocol(TCP) [40] or

theUserDatagramProtocol(UDP) [39] asa transport.Thefollowing quotefrom theRFC

givesadetaileddescriptionof SIP’s capabilities:

“The SessionInitiation Protocol(SIP) is anapplication-layercontrol (signal-ing) protocol for creating,modifying and terminating sessionswith one ormore participants. Thesesessionsinclude Internetmultimedia conferences,

10

Internettelephonecallsandmultimediadistribution. Membersin asessioncancommunicatevia multicastor via a meshof unicastrelations,or a combina-tion of these.SIPinvitationsusedto createsessionscarrysessiondescriptionswhichallow participantsto agreeonasetof compatiblemediatypes.SIPsup-portsusermobility by proxying andredirectingrequeststo theuser’s currentlocation. Userscanregistertheir currentlocation. SIP is not tied to any par-ticular conferencecontrol protocol. SIP is designedto be independentof thelower-layer transportprotocolandcanbe extendedwith additionalcapabili-ties.” [23]

SIP Network Elements

Network elementsrequiredto supportSIP are shown in Figure 2.1. The SIP RFC

[23] dictatesthata SIPserver canoperatein two functionalmodes:proxy or redirect. In

proxy mode,a server actsasa liaison andforward received messagestoward their desti-

nation. Redirectserversdo not passmessageson toward their final destination. Instead,

they inform the calling terminal of the currentlocationof the calledterminalso the two

terminalscancontacteachotherdirectly. TheRegistrar/LocationServer (RLS) mustpro-

vide onebasicfunction; a tablemappingSIP URIs to an IP addressfor eachuser. The

RLS functionality canbe incorporatedinto a SIPserver, but for enterpriselevel scenarios

it is not recommended.Separatingthetwo devicesrequiresa directoryservicesuchasthe

LightweightDirectoryAccessProtocol(LDAP) [69] or a multicast-basedprotocol [49] to

beusedfor queriesbetweentheSIPserverandRLS.TheSIPRFCdoesnotdirectly include

provisions for aMedia/SignalGateway(MSG),but it is neededto connecttheenterpriseto

thePSTN. ThetranslationbetweentheSIPor H.323signalingfacilitiesandtheSignaling

System7 (SS7)usedto controlPSTNcallsarebeyondthescopeof this work andreaders

shouldreferto [47, 48, 65]. Theuseragentsspecificationsstatethatbothclient andserver

capabilitiesmustbeincludedin anendterminal.This is requiredbecausetheterminalmust

takeon theroleof aclientwheninitiating acall andthatof aserverwhenreceiving acall.

11

Message Routing

Thedesignof SIPallowsacall to beroutedthrough numerousserversbetweenendter-

minals.To ensurethatall requestandresponsemessagesfollow thecorrectpatha tracking

mechanismis includedwith theprotocol.TheVia headerin boththerequestandresponse

messagesis usedto tracktheSIPserversthemessagehaspassedthrough.For requestmes-

sageseachSIPserver mustaddits addressto theendof theVia field. Thus,whentheend

terminalreceivestherequestit hastheexactpaththemessagetook with theserver closes

to it at the endof the list. The responsemessagegeneratedby the terminal will contain

a copy of the Via field with the last entry removed. The terminalwill usethe addressit

removed from the endof the Via list asthe destinationfor the responsemessage.When

a server receivesa responsemessageit removesthe lastentry in the Via field andusesit

asthe destinationaddressthe messageof the next hop. This processcontinuesuntil the

responsemessagearrivesat theoriginal terminal with the Via field empty. Theability to

tracktheapplication-level pathof themessagesalsoallowsSIPserversto detectloopsthat

theunderlyingprotocolsmaybeunawareof.

SIP Message Header Overview

Theaddressschemeusedin SIP is similar to electronicmail. EachURI is comprised

of a nameanda hostor domainseparatedby an @ sign (name@domain, name@host).

However, sincethereis thepossibilitythataSIPterminalwill becallingaterminal attached

to the PSTN and not the Internetthe SIP URI hasan additionalform. To reachPSTN

terminals,theURI containsthephonenumberandtheaddressof theMSGto routethecall

through(phone-number@gateway).

Thesix signalingmethodsincludedin theSIPRFCareoutlinedTable2.1.

In additionto therequestmethods,SIPincludesa fixedsetof responsemessages.The

responsecodesarebasedupontheonesusedin HTTP. Table2.2lists thesix categoriesand

a broaddescriptionof the categories. For a detaileddescriptionof individual responses,

12

Table2.1: SIPRequestMethods

INVITE This is themessagethat initiatesthecall. It includesinfor-mationaboutthecalling party, call-ID, call sequencenum-ber, calledpartyandusuallyanSDPdescriptionof call pa-rameters.It canalsobeusedto modify thecallsoperatingstatewhile thecall is takingplace.

ACK The calling agentrespondswith ACK only to INVITE re-queststhathavebeensuccessfullyacceptedwith a200code.TheACK canalsocontaintheSDPdescriptionof themediacapabilityof thecalledparty.

BYE A client sendsthis messagewhenacall is to bereleased.OPTIONS Thismessageis sentto querythecapabilitiesof acall agent.CANCEL If a requestis in progressthis messagewill causeit to be

canceled. The CANCEL messagemust include the call-ID, call sequencenumberandthesourceanddestinationtheoriginalrequestcontained.It hasnoeffectonanestablishedcall.

REGISTER ClientsusetheREGISTERmethodto registerthetheir ad-dresswith aSIPserver.

referto theRFC[23].

Table2.2: SIPResponseCodeCategories

1xx - Informational Proceedingwith theexecutionof therequest.2xx - Success The requestwas successfullyparsedand executedby the

calledparty.3xx - Redirection Thecall needsmoreprocessingbeforeit canbedetermined

if it canbecompleted.4xx - RequestFailure The requestcannotbe parsedby the server or cannotbe

serviced.5xx - ServerFailure Therequestmaybevalid, but theservercannotexecuteit.6xx - GlobalFailure Theuserrequestcannotbeservicedby any server.

An exampleINVITE requestis show in Figure2.2. Thesecondpartof the requestis

theSDPheaderandwill bediscussedin thenext section.

2.2.2 Call Control Using Session Description Protocol

While SIP is usedto initiatea call, it doesnot includethe capabilityto configurethe

parametersthat will govern the call including audioandvideo codecs.The SessionDe-

13

INVITE sip:[email protected]/2.0via: SIP/2.0/UDP192.168.0.80:5062from: sip:[email protected]: sip:[email protected]: [email protected]:1 INVITEcontent-type: application/sdpcontent-length: 250

v=0o=bereynolds84532652 84532652IN IP4192.168.0.80s=FeedbackonM.S.Thesisc=IN [email protected]=28733974962873404696m=audio4657RTP/AVP 0

Figure2.2: SampleSIPINVITE Message

scriptionProtocol(SDP)[22] is usedto describea multimediasession.The SDPheader

servesthreepurposes:thetypeof informationto beexchanged(audio,videoor both),how

thesendershouldencodethe informationandwhereto sendthe information. For unicast

callsthesenderof theSDPdescriptionis requestingthatthereceiverusetheconfiguration

specifiedin thedescriptionbut for multicastcalls theSDPmessageindicatestheconfigu-

rationthesenderwill useto transmit.

A sampleSDPdescriptionis includedat thebottomof Figure2.2. Many fieldsdefined

by theRFCarenot includedin this basicexample.TheRFC[22] containsa completelist

of fields andtheir full definitions. The following list providesa brief descriptionof the

fieldsusedin theexamplein Figure2.2.

� v = protocolversion(only version0 hasbeendefinedby theRFC)

� o = originatorof thesessionandsessionidentifier

� s= sessionname

� c = connectiondata

14

� e= emailaddressof originator

� t = time sessionis active

� m = mediaannouncementincludingmediatype,destinationport number, transportlevel applicationandmediaformat(codec)

2.2.3 Media Transport Using Real-Time Protocol

With the call setupcompletethe transmissionof mediais doneusing the Real-Time

Protocol(RTP) [50]. RTP consistsof two parts;RTP itself for transmitting the dataand

RTCP, Real-TimeControlProtocol,for real-timechannelcontrolandqualityof service.To

achieve ascloseto real-timedeliver aspossibleRTP runsover theUDP but is capableof

usingany transportlayerprotocol. TheRTP streamsusethedestinationportsincludedin

theSDPheaderof thecall. RTPalwaysusesanevennumberedportandthecorresponding

RTCP streamusesthe next odd numberedport. Unlike SIP and SDP, RTP is a binary

protocol.Figure2.3shows thecompletelayoutof aRTP packet.

2.2.4 SIP Call Models

TheSIPprotocol definesfour basiccall models.Thedirectcall modelshown in Figure

2.4 is themostsimplisticof thefour models.It representsa directcall betweentwo termi-

nalswithout theinvolvementof aSIPserver. Thefirst stepis to setupaTCPconnectionfor

thecontrolstreamof thecall. UsingtheTCPconnection,thecalling terminalsendsanIN-

VITE requestdirectly to thecalledterminal. This resultsin thecalledterminalgenerating

several responsesto inform the calling terminal of the statusof the call; trying andring-

ing. A successresponseis sentafterthecalledterminalanswers.A final acknowledgment

from the calling terminalcompletesthe call setup. As well a establishingthe call, these

initial request-responsemessagesconfigurehow the mediaflows will operateusingSDP.

Uponcall setupcompletion, themediaflow usingRTP begins. At theendof thecall, the

terminalsexchangeBYE messagesandcloseall openconnections.

15

Version HDLEN TOS Total Length (bytes)

Identification Flags Fragment Offset

TTL Protocol Number TCP Checksum

32-bit Source IP Address

32-bit Destination IP Address

Source Port Number Destination Port Number

UDP Length UDP Checksum

v p x cc m PT Sequence Number

Timestamp

Synchronization Source Identifier (SSRC) = constant per source

Contributing Source Identifiers (CSRC) (optional)

RTP Payload (audio, video, ...)

IP H

eader 20 bytes

UD

P

Hdr

8 bytes

RT

P H

dr

12 bytes

0 1 2 3 8 1 6

3 1

Figure2.3: RTP Packet Layout

The redirectcall modelcloselyresemblesthe direct call modelwith the exceptionof

the initial messagesequence.As Figure2.5 shows, thecalling terminalsendsanINVITE

requestto the redirectserver to obtain the currentaddressof the other terminal. Upon

receiving thecurrentaddress,anotherINVITE requestis sent.After this, thecall proceeds

asin thedirectmodel.

Theproxy call modelin Figure2.6canbeviewedastwo directcallsbridgedtogether.

Eachterminalcommunicateswith oneor moreintermediateproxy servers.Theendtermi-

nalscreateTCPconnectionswith theproxy. Theproxy thenforwardsmessagesbetween

the two terminals. The RTP mediastreamsdo not passthroughthe proxy, but aresent

directlybetweenthetwo endterminals.

ThePSTNcall modeldiffersfrom theothersin oneregard: thecall spansboththedata

network andthe PSTN.Figure2.7 shows how the MSG translatesthe variousmessages

betweenthe two networks. The sequenceof messagesfollows very closelyto the proxy

16

TCP Connection Setup

Calling Terminal userA@domain1

Called Terminal userB@domain2

INVITE From, To, Via, Call-ID, CSeq, SDP

trying (progress report, code 100) �ringing (progress report, code 180)

success - user accepted the call (code 200, OK)

ACK (may contain final SDP) �

The caller confirms receipt of success code

Media flow over RTP using dynamic UDP ports

BYE terminate call �

BYE terminate call �

success - call terminated in this direction (final, code 200)

success - call terminated in this direction (final, code 200)

Figure2.4: SIPDirectCall Model

17



INVITE (userB@domain3) From, To, Via, Call-ID, CSeq, SDP

ringing (180)

200 OK From, To, Call-ID, CSeq, Via

ACK userA@domain1 �may contain final SDP


BYE From, To, Call-ID, CSeq, Via

200 OK

INVITE (userB@domain2)

Redirect Server

moved Contact: userB@domain3

ACK �

Figure2.5: SIPRedirectCall Model




INVITE (userB@domain2)

Proxy Server for userB@domain2

trying (100) � INVITE (userB@domain2)

ringing (180) ringing (180)

200 OK 200 OK

ACK userA@domain1 �may contain final SDP ACK userA@domain1

�may contain final SDP

BYE BYE

BYE BYE

200 OK 200 OK

200 OK 200 OK

Figure2.6: SIPProxyCall Model

18

SIP Terminal userA@domain1

PSTN Terminal 555-5555


INVITE (555-5555@gateway)

Media/Signal Gateway

trying (100) �

IAM ACM

ringing (180) ANM

200 OK

BYE

REL RLC

200 OK

Figure2.7: SIPPSTNCall Model

call model.

In additionto thebasiccall models,SIPis alsocapableof providing multipartyconfer-

ences.SIPallows conferencecalls to beconstructedvia threedifferentmodes:network-

level multicast,dedicatedbridges(alsoknown asmultipoint control units) or a full-mesh

of unicastconnections.Eachmodefits certainconferencesettingsbetterthanothers.For

largeconferencesmulticastor bridgesaremorefunction, but for three-waycallingor small

groupsa full-meshof unicastconnectionsis a moreappropriateconfiguration.For addi-

tional informationon theconferencecallingcapabilitiesof SIPreferto [54, 55].

19

Chapter 3

STEM - Secure Telephony Enabled

Middlebox

To securelyprovideIP telephony serviceswithin anenterprise,securitymustbea ma-

jor considerationfrom thebeginning. This chapterfirst outlineswork thathasbeendone

to addressthe middleboxbox issue. However, aswasshown in the previous chapter, IP

telephony is a very complex application.Therefore,the entirenetwork architecturemust

beconsideredif theserviceis to bedeployedsecurely. This chapterintroducestheSecure

Telephony EnabledMiddlebox (STEM) architecture.The STEM architectureprovidesa

solid foundation to securelydeploy IP telephony andotherdynamicapplicationswithin an

enterpriseenvironment.While aSTEM enabledenterprisenetwork differsfrom traditional

enterprisenetwork andbasicIP telephony networks,it doesnot requireany modificationto

theIP telephony protocolsstack.

Theremainderof thechapteris comprisedof four sectionsdiscussingdifferentaspects

of theSTEM architecture.Thefirst sectioncoversthe requirednetwork componentsand

their functionalities with respectto the SIP protocol. (Note: the H.323 protocol works

very similarly.) Next, the protocolsusedin communicationbetweenthe components are

outlined. It is important that the IP telephony protocolscreatedby the IETF and ITU

20

operatenormallywithin a STEM network. Thethird sectionexaminesin detaila number

of call setupscenarios.The final sectiondiscussessomework that wasdoneto createa

prototypeof theSTEM architecture.

3.1 Previous Work

Solutionshave beenpresentedduring thepasttwo yearsthatattemptto solve someof

theproblemscausedby deploying dynamicapplicationsin staticenvironments.All of the

solutionsmodify themiddleboxeson theperimeterof anenterprise’s network, namelythe

firewall. Thissectionincludesanoverview of theprevioussolutionsto thestaticmiddlebox

problem.Thereadershouldreferencethecitedworksif a detaileddescriptionof thework

is required.

3.1.1 Application Layer Proxies

A solutionproposedin [33] by Jiri Kuthanexaminesthecreationof aprotocolto allow

manipulationof thefirewall configurationfrom anexternaldevice. In theirtopology, Figure

3.1,anew devicewasaddedfor handlingonly IP telephony traffic [33]. Thisnew devicesits

adjacentto thefirewall andall IP telephony controltraffic is routedthroughit insteadof the

firewall. The IP telephony proxy mayberequired to performnetwork addresstranslation

of thedatastreamsif theinternalnetwork usesprivateaddresses.

TheIP telephony proxyandthefirewall communicatevia aprotocolcreatedby Kuthan

calledFirewall Control Protocol(FCP).FCPallows the proxy to instruct the firewall to

passonly theRTPpacketsassociatedwith a IP telephony call. Theproxyextractstheports

thatwill beusedby theRTPstreamsduringthecall setupandinstructsthefirewall to allow

theappropriateRTPstreams.TheFCPmessagesallow theproxy to specifytheexacttuple

thatwill matchthemediastream.Thefine granularityof thestreamspecificationsis to to

ensurethatonly legitimatetraffic traversethefirewall.

21

SIP Proxy

FCP SIP

SIP

Firewall

External Host

Internal Host

Figure3.1: DecomposedFirewall Architecture

This solution off-loads the task of determining the port numbersusedby the media

flow from the firewall. Additionally, by not incorporating the proxy into the firewall, an

enterpriseis not dependenton updatesby firewall vendorsto be able to deploy IP tele-

phony. This solutionallows a large volume of calls to be handledwithout affecting the

performanceof thefirewall becausetheproxy handlesthebulk of thework. However, the

FCPmessagescancausea bottleneckin the system.With a large call volume, the over-

headof addingandremoving the rulesvia a user-spacedaemonon thefirewall would be

significant.Therearealsomajorsecurityissuessurrounding Kuthan’ssolutionthatarenot

addressed.He doescommentthat a real world deploymentmustconsiderauthenticating

theFCPmessageswhendeploying thissolution in ahostilenetwork. Suggestionsaregiven

to runFCPthroughanotherprotocolsuchasIPSec[63] or TransportLayerSecurity(TLS)

[15]. A cautionarymessagethatfirewalls shouldcheckall FCPmessagesagainsta basic

setof accesscontrolsbeforecommitting thechangesis alsoincluded.

A drawbackto this solutionis thatadditionaldevicesmustbeaddedfor eachdynamic

applicationdeployed. This will ultimately reducethe overall protectionprovided by the

firewall becausevarioustraffic will neverbeinspectedby it. In [33] it is assumedthateach

proxywill usetheirdetailedknowledgeof theprotocolto ensurethatonly legitimatetraffic

22

passesthroughthem,but hedoesnotmakeany assumptionsaboutthesecurityof thesystem

theproxy resideson. Theseadditional systemsarecompletelyexposedto theInternetand

couldbecomeadditionaltargetsfor attackerstrying to gainaccessto theinternalnetwork.

3.1.2 Layered Firewall Architectures

A new internalarchitecturefor enterprisefirewalls waspresentedin [43]. Within the

firewall are layersof abstractionare placedbetweenthe internal componentsas shown

in Figure3.2. Theselayers,calledadaptationlayers,exist betweenthe firewall, internal

operatingsystem,IP telephony parser, and external components.The layersprovide a

commonAPI betweeneachcomponent.This allows modulesto be interchangedwithout

any inconsistency assumingthemodule’s APIsareconsistent.

TheadaptationlayerbetweentheIP telephony parserandtheexternalinterfaceallows

communicationwith otherdevicesattachedto thenetwork. Thiscommunicationchannelis

by externaldevicesto querytheoperationof thefirewall andto allow thebehavioral mod-

ificationsto bemaderemotely. Thespecificsof theprotocolto beusedarenot addressed

in [43] nor is theissueof messageauthentication.By allowing externaldevicesto modify

theinternalcomponentsof thefirewall, apotentialhostiletargetmightbeableto causethe

firewall to operatein anundesirablemanner. Thisfirewall architectureallowsenterpriseto

useIP telephony, but thelackof authenticationmechanismsensurethatthissolutionneeds

additionalwork beforeit canbedeployed.

3.1.3 IETF Initiatives

Academicinstitutionsarenotalonein investigating theproblemof supportingdynamic

applicationsthroughstaticdevices. TheInternetEngineeringTask Forcehascreatedsev-

eralworkinggroups(WG) to examinedifferentaspectsof this area.

TheMidcom WG [24] wasformedto designa protocol similar to theFirewall Control

23

FW

FW Adaption Layer

Data Adaption Layer

IP-Telephony Parser

IP-Telephony Adaption Layer

OS �

to remote source �

configuration

to remote FW �

to IP-Tel components �

Figure3.2: AdaptionLayeredFirewall Architecture

Protocol(FCP)previously discussed.The WG haspublishedseveral preliminary docu-

mentsdescribingthe functional requirements the protocol must fulfill [57, 61, 5]. The

protocolis beingdesignedto allow it to beusedfor communication with a wide arrayof

network middleboxes.

Thereareseveralworking groupsdedicatedto theprotocolsusedby dynamicapplica-

tions. The SIP WG [26] andSIPPINGWG [25] are tasked with the creation,extension

andmaintenanceof theSIPprotocol[46, 44, 30, 38]. TheMMusic WG hasa similar re-

sponsibility for the SDPprotocol [22, 52]. Finally, the RTP protocol is assignedto the

Audio/Visualworkinggroup[50, 7].

3.2 Architecture Components

In designingtheSTEMarchitecture,oneoverallgoalwasto leverageexistingenterprise

infrastructure. The STEM network layout closelymirrors a typical convergedenterprise

24

Enterprise DMZ

SIP �

Redirect Proxy

SIP �

Registrar / Location Server �

Web �

Server �DNS

Server �

Edge Router

External Firewall

Internal Firewall

Softphone � IP Phone

Enterprise LAN

Authentication �

Server �

PSTN

Media / Signal �

Gateway �

Internet

Security �Manager

Figure3.3: SecureTelephony EnabledMiddleboxArchitecture

network structure.Figure3.3 is anexampleof a STEM enabledenterprisenetwork. The

enterprisenetwork is partitioned into two sections,the internal LAN and the DMZ, in

additionto beingconnectedto theInternetandPSTN.

A comparisonof Figures2.1 and3.3 shows thatnew componentsarerequiredby the

STEM architecture.However, several of the componentswithin the STEM architecture

includeenhancedfunctionality andfeaturesnot found in traditionalconvergednetworks.

The remainderof this sectiondiscussestheoperationof thenew componentsandtheen-

hancementsmadeto theexisting components.

3.2.1 Security Manager

Theoverall securityin STEM enabledenterpriseis centrallymanagedby theSecurity

Manager(SM).While theSM operatesastheoverseerof all operationswithin thenetwork,

it is not a physical entity. The functional units of the SM areincorporatedinto different

network elements.TheSM entity shown in Figure3.3simply functionsasa centralportal

into thedistributedcomponents. Thefour functional unitsof theSM area)URI mappings,

b) URI preferences,c) SPAM lists,andd) userauthentication.

Eachenduseror terminal will have a uniqueSIP URI. Within the proposedIP tele-

phony protocols, theURIsarenotboundto eithermachineaddressesor physicallocations.

25

Theimplicationof this is thatemployeesmayroamwithin anenterpriseandbeableto re-

ceivecallsto asingleURI. Therefore,amappingbetweentheURI andthenetwork address

of the machinethe employeeis currentlyat is very important. The SecurityManageris

responsiblefor maintainingthedatabasecorrelating useraddresses(SIPURIs) to network

addresses(IP addresses).Both IP telephony protocolsincludeprovisions for this type of

functionality. In SIP, theRegistrar/ LocationServer (RLS) is responsiblefor this. In addi-

tion to thebasicURI to IP mapping, informationmustalsobeincludedthatdeterminesif

theemployeeis connectedto theenterpriselocally or remotely. In thecaseof anemployee

connectingremotely, all incomingcallsmustbefirst routedthroughtheenterprise’sVirtual

PrivateNetwork (VPN) concentrator.

In additionto providing theURI mapping,theRLS is alsoresponsiblefor thesecond

functionalunit of theSM: theURI preferences.EachURI hasa setof preferencesassoci-

atedwith it. This includes,but is not limited to: automaticallyacceptnew calls,forwarding

calls to anotheruseror service(e.g. voicemail), automaticallydroppingcallsor querying

theuserwhenacall arrives.Theconfigurationof thesepreferencesdetermineshow theSIP

Proxywill routeincoming callsfrom boththeInternetandthePSTN.

Thethird componentof theSM is theSpamaddresslists. Thisconsistsof two different

list types. One is an enterprisewide list that resideson the SIP Proxy. Any incoming

call from an addresson this list is automaticallyrejected. The severity of this is large

enoughthat the list shouldonly beutilized in extremecasesandafterall otheravenueof

resolutionhave beenexhausted.The secondlist type is kept on a per URI basis. Again,

this information is storedby theRLS. Eachemployeeis ableto managertheir own list of

offendingaddresses.Uponreceptionof anew incomingcall, theSIPProxyqueriesthelist

storedon theRLS.

The final elementof the SM is a userauthenticationenforcementmechanism.This

is implemented in both the SIP Proxy andthe Media/SignalGateway (MSG). To ensure

thatonly legitimateusersareallowedto make outgoing calls,both theSIPProxyandthe

26

Flow Monitor Protocol Parsers

Pattern Matcher

External Interface

Operating System

To Security Manager

Figure3.4: InternalLayoutof STEM Firewall

MSG require usersto beauthenticated.Almost all enterpriseshave anexisting centralized

authenticationinfrastructure,therefore,theSIPProxyandMSGsimplyrequestthecreden-

tials provided to the endusersby the existing infrastructure. This caninclude,but is not

limitedto: activedirectory, Kerberos[32], andRadius[42].

3.2.2 Firewall

The firewalls within the STEM architecturefill an equally important as the Security

Manager. They ensurethat traffic flows follow a specificpathandprovide boundariesbe-

tweenthedifferentnetwork segments.To accomplishthis goal,thefunctional behavior of

the firewalls in the STEM architecturearemuchdifferent thantraditional firewalls. The

firewalls arecapableof parsingtraffic from dynamicapplicationsaswell asproviding tra-

ditional staticfiltering.

The internaldesignof thefirewalls in theSTEM architectureis anenhancementupon

existingdynamicdesigns.Thebasicinternallayoutwasadoptedfrom [43]. Theinteraction

of thediscreteinternalcomponentsisshown in Figure3.4.By designingeachcomponentas

a self-containedentity, it is possibleto dynamicallyloadandunloadthemwithout impact-

ing theotherfunctionsof thedevice. Eachclassof componentshave a commoninterface

to allow themto easilybeinterchangedandupgraded.

27

� Protocol Parser The most important block in the firewall architectureis the Proto-

col Parser. This componentis comprisedof multiple parsers.Eachparseris designedto

understandtheoperationof asinglecomplex protocol.

TheSIPparserincludesa call monitorcomponentthat is responsiblefor ensuringthat

eachcall follows the protocol specifiedstatetransitions. The dynamicport numbersare

extractedfrom thecall setupandpassedto thePatternMatcherwhichopenstheappropriate

pinholes.Thereis thepossibilityof two callsselectingthesameport numbers.Therefore,

the SIP parsermustmonitor both the port andinternal IP addressassociatedwith a data

stream.It will instructthePatternMatcherto completelycloseaportonly afterall streams

have terminated. Additionally, the parseralso extracts the mediacodecsadvertisedby

the terminalsduring call setup.This information is passedto the Flow Monitor to detect

maliciousstreams.

� Flow Monitor The Flow Monitor is designedto handlemaliciousdatastreams. It

monitors thedatarateof thecall streamsandif they exceedthethresholdsetby theband-

width requirementsadvertisedduringthecall setupthefirewall canrespond.Thetriggered

responsecanbe setby the individual network administrators andcould includedropping

packetsof themaliciousstreamor applyinga traffic throttling algorithm.

� Pattern Matcher ThePatternMatcheris themostbasiccomponentin thefirewall and

all packet filter firewalls includethis component. It allows configurationof staticrule-sets

usingmachineaddresses,transportprotocols, andport numberspecifications [59]. Each

rule-sethasanactionassignedto it thatis executedwhentherule is triggered.

� External Interface TheExternalInterfacecomponentallows thefirewall to communi-

catewith otherdevices. It is responsiblefor parsingincomingmessagesfrom othercom-

ponentsandgeneratingappropriateresponsemessages.

28

3.2.3 Media/Signal Gateway, SIP Proxy & SIP Registrar

All threeof thesecomponents have beenmodifiedslightly from their default behavior

in a convergednetwork. TheMedia/SignalGateway is theleastmodifiedcomponent.The

only modificationsis thevalidationengineusedto allow outgoingcallsto becompleted.

TheSIPProxyhasbeenmodifiedto querytheRegistrar/LocationServer for multiple

piecesof information including the IP addressthe called URI is currently registeredat

andhow to direct thecall or if it shouldbe rejected.It alsomustbeableto validateuser

credentialswhenanoutgoingcall is placed.

TheRLSnow muststoretheadditionalinformation outlinedpreviouslyaswell asallow

usersto make modificationsto this information. To ensurethatuserscanonly manipulate

their own information,theRLSmustalsoincludetheability to validateusercredentials.

3.3 Inter-Device Communication

Therearenumerouscommunication sessionsrequiredto haveaSTEMnetwork operate

smoothly. However, a large numberof thosecanbe handledby protocolsalreadybeing

usedwithin the network. All of the userauthenticationis handledvia the pre-existing

infrastructure. ThequeriesbetweentheSIPProxyandRLScanbedoneusingastructured

databaselanguagesuchasSQLor via servicessuchasLDAP. ThepreferenceandSpamlist

configurationsessionsbetweentheendusersandRLScanbedoneusingtheSIPprotocol.

Theonly communication sessionsthatrequireanew protocolarethosebetweentheSe-

curity Managerconsoleandthefirewalls. A configurationprotocolto allow amiddleboxes

internalstateto bemodifiedremotelyis currentlyunderdevelopmentby theIETF Midcom

WorkingGroup.A final versionhasnotbeenreleasedyet,but aprotocol requirements[60]

andarchitecturalframework [56] have beenreleaseddetailingtheoverall functionality of

thefinal protocol.

29

3.4 Example Call Scenarios

Thetopology of a convergednetwork andtheflexibility of the IP telephony protocols

resultsin a largenumberof call setupscenarios.Therefore,this sectiononly addressesthe

morecommontypesof callswithin anenterprisesetting.Thesescenarioscanbepartitioned

into four categories:Incoming Net-to-Net,OutgoingNet-to-Net,PSTN-to-NetandNet-to-

PSTN.For acomprehensive listing of call scenariospleasereferto [30].

3.4.1 Incoming Net-to-Net Calls

All incomingNet-to-Netcallsfollow thesamecall setup.Theexternalcalling terminal

initiatesa TCPconnectionto port 50601 of thedestinationterminal. Whentheinitial TCP

SYN packet arrivesat the externalfirewall, the SIP ProtocolParseridentifiesit asa new

call. TheparserroutestheSYN packet to theenterprise’s SIPProxy regardlessof the IP

addressthepacketwasinitially destinedfor.

TheSIPProxycompletestheTCPhandshakewith thecalling terminal. ThisTCPcon-

nectionwill beusedto transmitall of thecall setupinformation.Thecallingterminalsends

a SIP INVITE requestover the TCP connectionto the proxy. Whenthe INVITE passes

throughtheexternalfirewall, theProtocolParserextractstheportsthecalling terminalwill

useto transmittheirmediastreamwhenthecall begins.TheSIPProxyqueriestheRLSto

determinehow to handlethenew call request.If therequestis accepted,theRLS provides

theSIPProxytheIP addresstherequestis to besentto.

BeforetheINVITE canbeforwardedto thecalledterminal,aTCPconnectionmustbe

establishedbetweentheproxy andcalledterminal.After thecall requesthasbeenrelayed

to the called terminal, the proxy actsasa bridgebetweenthe two control channelTCP

connections.

In thecasewherethecalledterminalacceptsthecalls,Figure3.5a,theSIPOK response�SIPserverslistenon thewell-known port 5060 asspecified in theRFC[46].

30

External SIP Endpoint

External Firewall

SIP Redirect Server

Internal SIP Endpoint

TCP SYN (1)

INVITE (9) Trying (10)

Ringing (11) OK (12)

Call Established (15) (RTP Data Flow) BYE (16)

OK (19)

TCP SYN - ACK (2) TCP ACK (3)

INVITE (4)

TCP SYN (6)

TCP ACK (8) TCP SYN-ACK (7)

Trying (5)

Ringing (11) OK (13)

BYE (17) OK (18)

ACK (14) ACK (15)

(a)Successful


External Firewall

SIP Redirect Server


TCP SYN (1)


Ringing (11) Unavailable (12)

TCP SYN - ACK (2) TCP ACK (3)

INVITE (4) TCP SYN (5)


Trying (10) Ringing (11)

Unavailable (15)

(b) CalledParty is Busy

Figure3.5: IncomingNet-to-NetCall Flows - Part 1

31


External Firewall

SIP Redirect Server

Mobile IP Home Agent

INVITE (9)

Ringing (11)

OK (12)

Call Established (15) (RTP Data Flow)

BYE (16)


Ringing (11)

OK (13)

BYE (17)

ACK (14) �

ACK (15) �

Roaming SIP Endpoint

INVITE (9)

Ringing (11)

OK (12)

ACK (15) �

BYE (16)

(c) CalledParty is Roaming

Figure3.6: IncomingNet-to-NetCall Flows - Part 2

will containthe SDPfields specifyingthe ports the calledterminalwill usedto transmit

their mediastream. This information will be extractedby the ProtocolParsersin both

firewalls and the appropriatepinholeswill be opened. This messageconcludesthe call

setupphaseandthetwo terminalsbegin exchangingRTP mediastreamsdirectly.

If thecalledterminaldoesnot acceptthecall or is busy, Figure3.5b,theBusyHere or

Temporarily Unavailable responsewill begeneratedby thecalledterminal. TheProtocol

Parserswill remove a call from their watch tablesafter seeingthis responsebecauseno

additionalcall traffic exists.

It is alsopossiblefor thecalleduserto not beconnectedto theenterpriseLAN locally.

A usermustinform theRLS if they aretunneledinto theenterprisenetwork via a VPN or

someothermeans.Whenan incomingcall arrivesat the proxy for a userconnectedvia

a VPN, thecall is typically routedto eithertheVPN concentratoror thecalledterminal’s

HomeAgent[37]. Figure3.6cshows anexamplewherea call is routedthroughtheHome

Agentof anemployeeusingMobile IP.

32

3.4.2 Outgoing Net-to-Net Calls

The structureof outgoing Net-to-Netcalls follow a format similar to incomingcalls.

All calls mustbe routedthroughthe SIP Proxy locatedin the DMZ. To enforcethis, the

two firewallshavestaticfiltersin placeto only allow SIPtraffic from 1) theinternalnetwork

to theProxyand2) theProxy to the Internet.Thefilters, coupledwith theauthentication

requiredto makeoutgoingphonecalls,ensurethatunauthorizedusersarenotableto make

callsto theterminalson theInternet.

After establishingthe TCP connectionwith the proxy andauthenticating,the calling

terminalsendstheinitial INVITE request.Themessageflow afterthis is influencedby the

call beingacceptedor rejected.Figure3.7ashows anexamplewherethecall is accepted

while Figure3.7bshows whathappenswhenthecalledterminaldoesnot answerandthe

call is canceled.As in thecaseof incomingcalls,thefirewallsdonotopenthepinholesfor

acall until thecall acceptancemessageis sent.

3.4.3 PSTN-to-Net Calls

To allow calls to beplacedbetweenPSTN terminalsandterminalson an IP network,

eachterminal in theIP network mustbeassignedanaddressthatis capableof beingspec-

ified by terminals attachedto the PSTN,e.g., a phonenumber(or E.164number). To

allow E.164numbersto beassignedto IP terminals,theDNS servicewithin theenterprise

mustincludethe ENUM extension[17]. The resultof this global namingschemeis that

PSTNterminalsareunawarethey arecommunicatingwith terminalonadifferentnetwork.

Thetranslationbetweenthetwo network protocolstacksis performedby theMedia/Signal

Gateway.

Figure3.8ashowsthemessagesequencerequiredto connecta terminalonthePSTNto

oneon anenterprisenetwork. TheSS7network routesthedialednumberto theenterprise

MSG2. A voiceporton thegateway is allocatedfor theincomingcall. TheMSGtranslates�Detailsof SS7routingarebeyondthescopeof thiswork, referto [47].

33


External Firewall

SIP Redirect Server


TCP SYN (1)


Ringing (11)

TCP ACK (3) INVITE (4)

TCP SYN (6)


Ringing (12)

TCP SYN-ACK (2)

Trying (5)

OK (13)

BYE (16)

OK (19)

BYE (17) OK (18)

OK (14)

Call Established (15) (RTP Data Flow)

(a)Successful


External Firewall

SIP Redirect Server


TCP SYN (1)


Ringing (11)

TCP ACK (3) INVITE (4)

TCP SYN (6)


Ringing (12)

TCP SYN-ACK (2)

Trying (5)

CANCEL (13)

CANCEL (14) OK (15)

Request Terminated (16) ACK (17)

Request Terminated (18)

ACK (19) �

OK (14)

(b) CalledPartyDoesnotAnswer

Figure3.7: OutgoingNet-to-NetCall Flows

34

PSTN Endpoint

Originating Local Exchange

Media / Signal Gateway

SIP Endpoint

SETUP (1) IAM (2) INVITE (3)

Trying (4) Ringing (5)

ACM (6) OK (8) ANM (9)

ALERTING (7)

CONNECT (10)

Call Established (11)

REL (13)

BYE (17) OK (18)

RLC (15)

DISCONNECT (12) RELEASE (14)

RELEASE COMPLETE (16)

(a)Successful

PSTN Endpoint

Originating Local Exchange


SIP Endpoint

SETUP (1) IAM (2)

REL No Avaiable Circuits (3)

RLC (5) RELEASE (6)


DISCONNECT (4)

(b) VoicePortsareFilled

Figure3.8: PSTN-to-NetCall Flows

35

the E.164numberto an IP addressusingENUM. After the destinationaddresshasbeen

resolved, the gateway establishesa IP telephony (e.g., SIP) connectionwith the called

terminal. In this scenario,thecalledterminalacceptsthecall andthemessageis relayed

throughthegatewaybackto thecalling terminal.Whenthecall terminates,theappropriate

tear down messagesare transmitted,the circuits are released,and the voice port in the

gateway is freed.

It is alsovery possibleif therearea largenumberof crossnetwork calls, thatwhena

new call reachesthe MSG thereareno availablevoice ports. Whenthis happens,a busy

messageis returnedto thecalling terminal asshown in Figure3.8b.

3.4.4 Net-to-PSTN Calls

Callsoriginatingfrom theenterprise’s LAN for terminalson thePSTNarestructured

in a similar mannerto thosedestinedfor terminals on the Internet. Insteadof usingthe

SIP Proxy asa bridgebetweentwo TCP connections,the MSG is used. The usermust

first authenticateto the MSG beforesendingan INVITE requestandhaving a voice port

allocated.For callsdestinedfor thePSTN,theURI within the INVITE requestmustuse

thealternateform. ThedestinationterminalsE.164numberis usedastheuserfield andthe

MSG’s IP addressis thehostfield whenconstructingtheURI.

TheMSG translatestheINVITE messageinto theSS7IAM message.TheIAM mes-

sageis routedvia the SS7signaling interconnectsto the TerminatingLocal Exchange

(TLE). For successful calls,suchastheoneshown in Figure3.9a,theTLE alertstheend

terminalandthecall continues.

For calls wherethe called PSTN terminal is busy the TLE returnsa Release(REL)

messagewith thebusyflagset.Figure3.9bshowsthattheMSGtranslatestheRELmessage

into aSIPBusyHere responsewhich is returnedto thecalling terminal.

36


Terminating Local Exchange

PSTN Endpoint

INVITE (1)

IAM (3) ALERTING (4)

ACM (5) �

CONNECT (7) ANM (8)

Ringing (6)

OK (9)

Call Established (11) (RTP Data)

REL (14) RELEASE (15)


RLC (16)

OK (13) BYE (12)

Trying (2)

ACK (10)

Call Established (11) (Voice)

(a)Successful

PSTN Endpoint

Terminating Local Exchange


SIP Endpoint

INVITE (1)

IAM (3) REL BUSY (4)

Trying (2)

RLC (5)

ACK (7) Busy Here (6)

(b) CalledParty is Busy

Figure3.9: Net-to-PSTN Call Flows

37

3.5 Implementing a Prototype of STEM

A rapidprototype implementationof theSTEM architecturewasattempted.Thevar-

iouscomponentswereto bebuilt upona modifiedversionof theLinux operatingsystem

[2]. However, it wasdiscoveredaswork progressed,that the currentstateandfacilities

provided by the 2.4 serieskernelwasnot sufficient. This sectiondiscussesthe approach

thatwasadoptedto implementSTEM.

3.5.1 Building a Dynamic Firewall

Theimplementationof thedynamicfirewall neededin theSTEM architecturewasthe

biggestchallenge.The 2.4 seriesLinux kernel incorporatesthe Netfilter firewalling sub-

system[3]. As shown in Figure3.10, thereareseveral kernelhookswithin Netfilter that

allow modulesto gain accessto packetsat differentprocessingstages.In additionto pro-

viding well definedpointsin therouting paths,theframework alsoallows for thecreation

of ProtocolHelpermodulesto allow thesubsystemto parsecomplex protocols.Thesetwo

propertieswerethedecidingfactorsto useLinux asthebasefor implementingourdynamic

firewalls.

Thestaticfilter capabilitiesarewell definedandimplementedin theexisting Netfilter

codeaswell astheability to do statefultrackingof connections.EachProtocolParserin

the new dynamicfirewall could be written asa ProtocolHelpermoduleanddynamically

loadedandunloadedwithin the firewall asneeded.Becausethis wasonly going to be a

prototype,only aSIPProtocolParserwasto bebuilt.

The Flow Monitor componentin the new firewall wasdesignedto be built uponthe

Traffic Control(TC) framework availablein the2.4serieskernels.

38

Incoming Packet Hook 1 -

Pre-Routing Route

Hook 4 - Post-Routing

Hook 2 - Local In

Outgoing Packets

Route

Hook 5 - !

Local Out

Packet Routed to

Local Process

Packet Created by Local Process

Hook 3 - Forward

Forwarded Packets

Figure3.10:NetfilterHookLayout

SIP Protocol Parser

Incoming Connection Mangling All incomingSIPcallsto theenterpriseareroutedto a

centralSIPserver. This requirestheIP addressto bemodifiedfor all SIPtraffic. TheDes-

tinationNetwork AddressTranslation(DNAT) hookin Netfilterallowsamoduleto change

thedestinationIP addressof an incomingpacket. By creatinga tupleandmaskto match

any incomingtraffic to port 5060,all incomingcalls andrelatedcall control information

canbere-routedto any destination.TheSourceNAT (SNAT) hookallows thereverseop-

erationto bedone. This allows theexternalhoststo believe they aretakingdirectly with

thecalledhostbut areactuallybeingrelayedthroughtheproxy.

TheRTPstreamsarenotproxiedthroughthecentralserver, but areconstructedbetween

thetwo endterminalsdirectlyandtherefore,it is notnecessaryto mangletheIP addressof

thepackets.(Note: seesectiononNAT for specialcase).

Tracking SIP Call Control Flows TheSIPprotocolprovidesa call control framework

to setupandmanipulateIP telephony calls. It canoperateoverany transportlayerprotocol,

but mostimplementationsuseeitherUDP or TCP. Eachendterminalmustprovide botha

39

client interfaceanda server interface.Therefore,unlike mosttransportlevel connections,

two uni-directionalstreamsareassociatedwith eachcall control. This situationis further

complicatedbecausesomesoft-phoneimplementationssendeachcontrolmessageover a

differentsocket. As a result,a largenumberof datastreamsarelogically linkedto asingle

call.

Theconnectiontrackingcapabilityof Netfilter allows for helpermodulesto bewritten

for protocols which do not operatein a standardfashion.However, the currentdesignof

theconnectiontrackingelementdoesnothandlemultiple relatedstreamseasily. Addition-

ally, becauseeachstreamonly hastraffic flowing in onedirection,it becomesdifficult to

associatethedifferentstreamswith asinglelogical connection.

Ensuring Validity of Control Message Content Theability to addintelligenceto afire-

wall is a big improvement.However, to ensurethatthetraffic is legitimaterequiresa large

amountof expensive contentchecking. A connectiontrackinghelpermodulecaneasily

includebasicsanitychecksfor differentprotocols.For theSIPhelper, it is easyto verify

that the first line of the messageconformsto the protocolspecifications.However, any

checkingbeyondthataddsa greatdealmorecomplexity. SIPallows for hostnamesto be

usedwithin theprotocolmessagesaswell asIP addresses.However, theuseof hostnames

createssignificantproblems.Thereis currentlynowayto resolveaDNSnamefrom within

theLinux kernel.To verify thatanembeddeddomainnameis legitimatewould requirethe

kernelto interactwith someform of asynchronousDNS resolver operatingin user-space.

Implementing theresolver andverifying thatthekernelwould not block while thenameis

beingresolvedis adifficult task.

TheSIPcall signalingis very complex. Thesmall numberof requestmessageprimi-

tivesmeansthat they areusedin numerousdifferentmannersto provide the featuresSIP

offers. The INVITE requestcanbeusedfor initiating a call, placinga call on hold, three

way calling or multi-partyconferencecalls. Therefore,ensuringthateachmessageis syn-

40

tactically correctandlogically valid is very difficult. The finite statediagramfor all call

messageflows is very large. Incorporating in a helpermodule the capabilityto parsethe

entireSIPmessageandalsomaintaining statefor a largevolume of callswould requirea

hugeamountof processingpower.

Multiple INVITEs per Call TheSIPcall modelallowsfor multiple INVITE messagesto

begeneratedfor eachcall session. Featuressuchascall hold,call forwardandcall parkare

all implementedusingadditionalINVITE messageswith differentheaderconfigurations.

The useof multiple INVITE messagesis alsoa techniqueto performa denialof service

(DoS) on an endterminal. It canbe difficult to differentiatebetweenmultiple legitimate

INVITE messagesanda DoSattack.Chapter5 fully addressesthe issueof detectingand

respondingto DoSattacksin theSTEMarchitecture.

Incorporating NAT Functionality At theIP layer, providing Network AddressTransla-

tion (NAT) functionality is not difficult. However, doingthesameat theapplicationlayer

is not straightforward. If theenterprise’s internalnetwork usesprivateaddresses,all com-

municationwith externalpartiesmustutili ze network addresstranslation.Therearetwo

significantproblemswith providing NAT for SIP.

First, the variablenatureof the headerfields makes it hardto determinewhat is and

is not applicablefor beingNATed. Assumingtheparsercouldguaranteethatall fieldsare

detected,asecondproblempresentsitself. CertainfieldscaneitheruseIPaddressesof DNS

namesto specifyhosts.If privateDNS namesareutili zed,they mustfirst beresolvedinto

IP addressesbeforeNAT canoccur. As mentionedearlier, it is currentlynot possibleto do

addressresolutionfrom within kernelspace.Usingtheasynchronousresolverworkaround

introducesanumberof timing issues.

Anotherissuerelatedto NAT is encounteredwith the RTP streams.Two consecutive

ports are requiredfor eachRTP sessionfor the control and datastreams. The existing

NAT behavior doesnot guaranteethat after the portshave beenNATed they will still be

41

consecutive. The currentNetfilter framework doesnot include a reservation schemeto

ensurethatafterbeingNATed,theportsarestill consecutive.

Dynamically Adding and Removing Pinholes TheNetfilterframework providesseveral

user-spacetools to allow the static filter setsto be manipulated. However, doing these

manipulationsfrom othersectionof kernelspaceis not permitted. Therefore,addingand

removing the pinholesrequiredto allow the multiple datastreamsfor eachcall would

requirethekernellevel ProtocolParserto invoke a user-spaceapplicationeachtime. The

overheadof transferring informationbetweenuserandkernelspaceaswell astheloading

andexecutionof a user-spaceapplicationwould dramaticallyreducethe performanceof

thefirewall.

Does Packet Encryption Break Everything? All of the problemsdiscussedthus far

have beenrelatedto implementation detailsof theProtocolParser. SIPallows for almost

all of the packet contentsto be encryptedincluding many of the headerfields. The only

fieldsthatmustremainin cleartext arethoseusedto routethecontrolmessageto thenext

hop. This meanstheentireSDPheadercanbeencryptedincludingtheportsto beusedby

the RTP streams.Requiringthe firewall to decrypteachSIP messageaddsa tremendous

amountof overheadin additionto thecryptographicproblemsof key distribution andtrust.

Thereareseveral potentialworkarounds to the problemincluding usingencapsulationor

redundantheadersbut thesearenot truesolutionsto theproblem.

Performance & Scalability

TheProtocolParsersneedto behighly efficientpiecesof code.However, incorporating

many of theworkaroundsandfixespreviouslydiscussed,resultin codethatis anythingbut

that.Themodificationof thestaticfiltersfromuser-spaceisaslow andexpensiveoperation.

In addition,if someform of aggregationof rulesis notdone,therulesetswill grow linearly

with thenumberof callsandsystemdegradationwill occurathighcall volumes.

42

The Flow Monitor mustoperatein real-time,which is a very dauntingtaskgiven the

amountof traffic it mustanalyze.Therefore,someform of packet samplingmustbeem-

ployed. Theperformanceof themonitor will greatlydependon thespeedandaccuracy of

thesamplingalgorithm.

3.5.2 Incorporating the Security Manager

The Vovida OpenCommunication Application Library (VOCAL) [4] was chosento

provide the SIP Proxy andRegistrar / LocationServer. The VOCAL suiteprovided an

opensourceimplementation of both servers. The VOCAL sourceis well laid out and

commentedto allow extensionsto beeasilyincorporated.Thefour functionalunitsof the

SecurityManagerfit extremelywell into the existing codebase.The work on addingall

theextensionsnecessaryto implementtheSM wasnot completedonceit wasdetermined

it wasnotpossibleto build thefirewall.

43

Chapter 4

Vulnerabilities in Converged Networks

Themorecomplicateda systembecomes,themorelikely therewill beflaws andvul-

nerabilitieswithin it. Convergednetworks areno exceptions. In a standarddeployment,

a largenumberof potentialvulnerabilitiesexist. This chapterprovidesanenumerationof

severalmajorclassesof vulnerabilitiespresentin aIP telephony enablednetwork andgives

severalpossibleattacksfor each.

4.1 Information Gathering

Thecollectionof informationcanbea very powerful tool. Oftentimesanattacker will

attemptto gain a large amountof information aboutnetwork topologys, device configu-

ration and traffic behavior patternsbeforeattackinga target. The SIP protocol includes

severalpotentialavenuesto allow attacksto gain valuableinformationabouta targetwith-

out introducing abnormalbehavior into thesystem.

TheSIPOPTIONSrequestallowsanindividual to querythecapabilitiesandresources

availableon a remoteterminal beforeestablishinga call. In anattemptto discover a net-

work’s topology layout, the Max-Forward headerfield can be usedto determinehow

many proxiestherearebetweentwo terminals.This techniqueis similar to thatusedby the

tracerouteutility. A third techniquecanbeusedto blindly scanfor IP telephony enabled

44

terminals.An IP telephony terminalreceiving a CANCEL requestfor a sessionthatdoes

not exist will automaticallygeneratea TransactionDoesNot Exist response.By sending

CANCEL requeststo a large numberof hosts,an attacker can determine if they are IP

telephony terminalsor traditional computers.

4.2 Eavesdropping

Third partydatacaptureis a seriousproblemin any sharednetwork. In convergednet-

works,it is potentiallyeasierfor anattacker to capturetheir desiredinformation.Without

preservingtheintegrity of thecontrolmessages,it is possiblefor a third partyto influence

the patha call follows. In addition, proxiescanbe addedto the routepathto ensureall

controlmessagesarepassedthroughahostcontrolledby theattacker.

In additionto having theability to re-routecalls,theinformation transmittedover tele-

phonecallshasthepotentialto containveryvaluableinformation.Utili tiesexist to decode

the RTP mediastreamsin real-time andplay voice backasa wave file on a third parties

computer[41]. Additionally, eavesdropping cancollectDual ToneMulti-Frequency infor-

mationtransmittedduring thecall including voicemail passwords,calling cardnumbers,

bankaccountsor creditcardnumbers.

4.3 Connection Hijacking

Thenext stepbeyondeavesdroppingoncallsis takingcontrolover thecall or hijacking

it. Sessionhijackinghasbeendoneat the transportlayer in thepast.UsingSIP it is pos-

sibleto performsessionhijackingat theapplicationlevel. An attacker who sendsfalsified

responsemessagesincludeMovedPermanently, MovedTemporarily or UseProxy to an

endterminalwill beableto redirectcallsto adifferentterminalthanintended.An attacker

could also issuea new INVITE requestwith a differentcall configurationor modify the

45

valuesof theSIPheadersasthey arein routebetweenthetwo endpoints.

The control streamof a call is not the only part susceptibleto hijacking. An attacker

could generatea RTP mediastreamdestinedto a particularvictim andusethe Synchro-

nizationSource(SSRC)identifierof thetarget.By ensuringthesequencenumberandtime

stampsarehigherandnewerthanthetarget,thevictim will heartheattackersmediastream

unknowingly.

4.4 Denial of Service

The final category of attacksis the mostdestructive. Denial of service(DoS) attacks

have the ability to completelyremove the usefulnessof a device. Almost every element

in a network aswell aseachlayerof thenetwork stackcanbethevictim of a DoSattack.

Thissectionwill focusonasmallsubsetof all possibleattacks.Thefour attacksdiscussed

are thoughtto be the mostdestructive flood basedDoS attacksin a convergednetwork.

Thefirst threefocuson attacksprimarily launchedfrom theInternet while thefinal oneis

aPSTNbasedattack.

� TCP SYN Flood A possibleDoS target is the network stackon the victim machine.

TheTCPSYN flood is anattackwhich attemptsto overwhelmthevictims’ network stack

by sendinga hugenumberof TCPSYN packetsto thevictim [11]. Doing this causesthe

victims computerto beunableto servicelegitimateincomingSYN packetsandtherefore

serviceis deniedto thosetrying to connectto thevictim. Thisattackis mosteffectivewhen

it is directedatamachinethatprovidesservicesto alargevolumeof clients.TheSIPProxy

andwebserverswithin anenterpriseDMZ arethemorelikely targets.

� SIP INVITE Flood Converged networks add a level of targetsthat are not usually

consideredin traditional datanetworks: humans. A SIP INVITE flood is a DoS attack

againsta human. The attackis launchedby establishingmultiple TCP connectionswith

46

anendterminalandthengeneratinga largenumberof INVITE messages.EachINVITE

messagemust be dealt with individually by the targetedhuman. Generatingenoughof

theserequestwill overwhelmthetargetandeitherconsumeall of their time answeringthe

requestor they will simply ignorethe telephony terminal andpotentiallymisslegitimate

calls.

A variant to this is generatinga moderatenumberof requeststo a large numberof

targets. This will not result in a DoS at the humanlevel, but ratherthe SIP Proxy could

becomeoverwhelmed. This hasthepotentialof causingtheproxy to dropor missrequest

and responsemessagesfrom existing calls. While the SIP protocol hasre-transmission

properties,thecall setuptime is greatlyincreasedif they areused.

� Malicious RTP Streams The link connectingtheenterprisenetwork andthe Internet

is anotherpotentialtargetfor attack.By increasingthevolumeof traffic beyondthecapac-

ity of the link, the quality of servicefor all datatraffic is degraded. IP telephony allows

for a new typeof bandwidthconsumingflood to belaunched.TheRTP packetsthatcarry

the encodedvoice dataare typically very small but aregeneratedin large numbers.An

attacker usinga modifiedSIP soft-phonecould createunusuallylarge RTP packets. The

extra informationwithin thepackets,if constructedproperly, would eitherbediscardedat

the receiving terminalor convertedinto frequenciesoutsidetheaudiblerange.Theoper-

ator of the receiving terminalwould not even be awarethey areunderattack. If enough

RTP streamsgoingto a targetnetwork wereof this maliciousnature,it couldsaturatethe

enterprise’s Internetconnection.

� Voice Port Exhaustion A convergednetwork alsoallows for new typesof DoSattacks

to beexecutedthat impactboththedataandphonenetworks. TheMedia/SignalGateway

containsafinite numberof voiceports.Shouldall of theportsbeallocated,nonew callscan

47

beinitiatedbetweenthePSTNandtheenterprise’s LAN1. A new DoSattackexploits this

by attemptingto establishandmaintainenoughcallsbetweenthe two networks to ensure

all othercall attemptsaredenied. This attackcancomefrom eitherthe internalLAN or

from thePSTNif enoughphonesaremarshaled.With thelimi tedIP telephony deployment

today, theneedto communicatewith PSTNterminalsis vital for any enterprisedeploying

IP telephony. Therefore,from botha financialandproductivity impactperspectivesthis is

themostcostlyform of DoSattack.

�This canhappenduringnormaloperatingconditions if thenumber of voiceportsto handletheexpected

outgoing call volumehasnotbeen correctlydetermined

48

Chapter 5

Secure IP Telephony using Multi-layered

Protection Framework

To ensurethearchitectureoutlinedin Chapter3 is protected,amulti-layeredframework

mustbedeveloped.Thischapterbeginswith anoverview of relatedwork doneonhandling

anddetectingdenialof serviceattacksin traditional dataandPSTNnetworks.A property-

orientedvulnerability analysisfor IP telephony is given. To ensureresourcefairness,four

differenttypesof sensorsto detectandcontrol flood basedDoS attacksthat make up the

SecureIP Telephony usingMulti- layeredProtection(STUMP)framework areintroduced.

Thefinal sectiondiscussessomequantitative resultsof onesensor.

5.1 Previous Work

ProtectionagainstDoS/DDoSattackshasbeena populartopic in recentyears. The

trendhasbeento focuson intrusiondetectionfor DoS,attackresponse(e.g.,reducingthe

impactof a DDoSattackinstance),and,sourcetracingandidentification.Sincethescope

of thiswork is notonattacksourcetracing,only relatedworksin detectionandresponseof

DoSattackswill bedescribedhere.

49

Accurate,efficient,andfastdetectionof DoSattackinstancesis thefirst andcritical step

in successfullydefendingthe target systemsagainstvariousformsof DoSattacks.Wang

etal [67] introducedasimplistic,yetpowerful, algorithmthatexploits thenormalbehavior

of TCPtraffic to detectthepresenceof a SYN flood attack. Their algorithmwasusedas

a basisfor the algorithms presentedin this work. Also, in [35], the methodof EWMA

(ExponentiallyWeightedMoving Average)is usedto detectDoSattacksagainstQoSin a

DiffServnetworkingenvironment.

Yauet al [68] developeda schemeto includethrottleson thenetwork routesthatusea

leaky-bucket approachto reducethe incomingrateof traffic to targetedservers. Another

approachto counteringDoSattacksatthenetwork infrastructureis theuseof Pushbackand

AggregateCongestionControl [36, 19, 28]. Thework onDoSattacksis alsonot limited to

only IP basednetworks. In [10], theauthorsexaminemediastimulatedfocusedoverloads

in thePSTN.

Someexisting solutions have beendevelopedto handlespecificDoS attackson the

targetedterminals suchasTCP synflood. For instance,both SYN cookies[9] andSYN

cache[34] areextensionsto thenetwork protocolstackin anattemptto reducetheresource

consumptionof eachincomingSYN packet.

Yetanotherapproachto reducingtheimpactof aDoSattackis from aqualityof service

(QoS)point of view. By limit ing theamountof resourceseachtypeor aggregateof traffic

canconsume,theextentof a DoSattackcanbeseverelylimited. In [20], Garg andReddy

presenta prototype systemcapableof enforcingQoSrestrictionson variousresourcesin-

cludingnetwork bandwidth,protocolstatememorybuffersandCPUcycles.

50

5.2 Property-Oriented Vulnerability Analysis for IP Tele-

phony

To protecta complex network system,suchasanIP telephony enabledenterprisenet-

work, thefirst stepis to comprehensively analyzethepotentialsecurityvulnerabilities.We

classifypossibleattacksaccordingto the securityproperties(or requirements)that these

attacksaretrying to violate. For IP telephony, thethreemaindesirablesecurityproperties

are: a) accesscontrol to usethe IP telephony service,b) integrity andauthenticityof the

IP telephony signalingmessages,andc) resourceavailability andfairnessin providing IP

telephony service. Otherproperties suchasconfidentialityandaccountability, dueto the

spacelimi tation,areoutof thescopeof thispaper. Thissectioncontainsabrief explanation

of eachof the properties,andillustratepossibleattackscenariosagainsttheseproperties.

Wewill alsodescribevariousmechanismsto mitigate theseattacks.

5.2.1 Access Control to Use the IP Telephony Services

With the deploymentof wirelessnetworks within enterprises,the probability that an

unauthorizeduserwill beableto connectto theinternalLAN hasgreatlyincreased.There-

fore, it is entirely feasibleto assumethatanattacker will beableto make telephony calls

onceattachedto thenetwork by any medium.To ensurethatthis is notpossible,all outgo-

ing callsmustbemadeby authenticatedusers.Mostenterpriseshavesomeform of central

authenticationserverin theirorganizationsuchasactivedirectory, Kerberos[32], or Radius

[42]. To preventunauthorizedoutgoingcalls,deviceswithin thecontrolpathmustbeable

to querytheauthenticationserver to ensuretheidentity of thecaller.

51

5.2.2 Integrity and Authenticity of the IP Telephony Signaling Mes-

sages

Signalingmessagesin a IP telephony systemshouldNOT betamperedandrepudiated

in any way, and violating this integrity and authenticity propertywill causepotentially

seriousservicedisruption. For instance,anattacker canmaliciouslyimpersonateothersto

sendSIPCANCEL requestmessagesto dropall incoming callsto a particularterminal or

to cancelall outgoingcalls madeby an individual. Anothertechniqueis to senda BYE

requestmessageto all theterminalsinvolvedin analreadyestablishedcall. This resultsin

thecall beingdroppedandtheterminalshaving to reestablishit. A third typeof attackson

signalingmessagesis causedby anattackergeneratingillegitimateSIPresponsemessages

informing thecalling terminalthatthecalledaddressis no longeravailable.

Yet anotherclassof attackis basedon call redirection. By injecting maliciousSIP

responsemessagesinto anexistingcall controlstream,anattackercanaltertheserversthe

control streamis routedthrough. If desired,they canforce the call to be routedthrough

a compromisedproxy. Otherresponsescanbe generatedto causethe calling terminal to

believe thecalledpartyhaseitherchangedlocationsor address.An attacker re-registering

with aRegistrar/LocationServerby sendingaSIPREGISTERrequestwith anew URI for

the target party is anotherattackin this class.The result is that all future incomingcalls

will beroutedto thenew URI allowing theattacker to impersonatethetarget.

All theabove examplesarerelatedto maliciously modify or insertsignalingmessages,

while theattacker canbeeitheraninsideror anoutsider. Only beingconcernedaboutout-

siderattacksallows simplesymmetricauthentication protocolson thecontrolchannelsare

sufficient to eliminateall thevulnerabilitiesrelatedto thepropertiesof authenticationand

integrity. On theotherhand,for insiderthreats,thesituationis significantlymorecompli-

catedassomeof the threatscannot be handledeven with the mostadvancedpublic key

protocolsalone.In suchcases,bothpreventionandintrusiondetectionmechanismsmight

52

needto beintegrated.For instance,applyingtheconceptof “property-oriented”detection

[66] allowsthefurtherseparationof amainproperty into ahierarchy of sub-properties,and

thendevelopsensorsto detecttheviolationsagainstany of thesub-properties.

5.2.3 Resource Fairness and Availability in Providing IP Telephony

Services

In aIP telephony system,resourcessuchasbandwidthmustbeallocatedefficiently and

fairly to accommodatethemaximumnumberof callers.This propertycanbeviolatedby

attackerswho aggressively andabusively (but maybelegally aswell) obtainunnecessarily

large amountof resources.In otherwords, the resourceshave beenunfairly distributed

amongall thecallers. Alternatively, theattacker cansimply flood thenetwork with large

numberof packets/messagessuchthat the resourcesareunavailable to all the callers,in-

cludingtheattackerhimself/herself.

Similarto theideasof FRED(Flow-basedRandomEarlyDropping)orACC(Aggregate-

basedCongestionControl), anetwork devicecanmonitortheresourceusagefor eachdata

stream(a micro flow) or a smallaggregateof datastreams(a macroflow). By usingsam-

pling schemes[16, 13,29], this device will beableto trackthenumberof packetssentper

flow andalsomonitorthesizeof thepackets.If a flow is determinedto beabusive, thede-

vice caneithernotify anadministratoror activateresponsemechanismslike peraggregate

ratelimi ting.

Dealingwith flood basedDoSattacksis muchmorecomplicated,especiallywhenthe

floodscanhappenin threedifferentlevelsin IP telephony: users,contactpointssuchasSIP

proxy, andnetwork links. To furthercomplicatethesituation,theattackscancomefrom

eithertheInternetor thePSTN.While thesearetwo verydifferentnetworksbothtopology

andfunctional wise,therearestriking similarities.

Thepacket switchingnatureof datanetworksallows multiple connectionsto sharethe

samephysical channel. Therefore,unlike in circuit switchednetworks, an IP telephone

53

terminalcanreceive andpotentiallyparticipatein multiple callsat once. An attacker can

easily overwhelma single terminal by sendingseveral call INVITE requestsin a short

periodof time.

The secondlevel of the flooding target is the internalcontactpointsin the enterprise.

For Net-to-PSTNandNet-to-Netcalls,thisis theSIPProxy, and,for PSTNbasedcalls,it is

theMedia/SignalGateway (MSG). Eachof thesedeviceshasa finite amountof resources

which every call requires.The MSG containsa fixed numberof voice ports. Every call

occupiesa singleport for theentiredurationof thecall. For callsbeingsentthroughthe

proxy, theresourcelimi t is notasfinite asthePSTNequivalent.However, theserveracting

astheproxy doeshave a limit amountof memoryandprocessingability, thussetsa limi t

on the numberof simultaneouscalls it canhandle. A large volume of calls could result

in theseresourcesbeingcompletelyconsumedanddenying any furthercalls. It shouldbe

notedthatthis conditioncouldoccurundernormaloperation.

The third level of attacktargetsincludesnetwork links connectingthe enterprisenet-

work to the global network. For access to the PSTNnetwork, this is the SS7signaling

link betweentheMSG andtheSTP. Theselinks aretypically 56 kbps.Theothernetwork

links connectthecorporateLAN to theInternet.If enoughtraffic is sentinto or out of the

enterprise,theselinks canbecomesaturated.Sincethenetwork link betweenthecorporate

LAN andtheInternetcarriestraffic otherthanjust IP telephony, saturatingthis connection

will resultin all servicesbeingdisrupted.

5.3 Sensors for Detecting DoS Attacks

This sectiondescribesa multi-layer architecturethatprovidesprotectionagainstflood

basedDoSattacks.Thearchitectureemploys four typesof sensorsto detectandcontrola)

applicationlayerfloodattacksusingSIPmessages,b) transportlayerfloodattacks,c)PSTN

originatedfloodattacks,andd) floodattacksusingRTPstreams.Thefollowing subsections

54

describethe functionality of thesesensorsandpotentialresponsesafter a certaintype of

attacksis detected.The detailsof the detectionandresponsealgorithmsareincludedin

Section5.4.

5.3.1 Application Layer Attack Sensor (ALAS)

Thekey objective of anALAS is to detectandcontrolDoSattacksthatexploit appli-

cationlayer signalingandcontrol messages,i.e., SIP messages.The target of the attack

couldbeanindividualuserand/ortheSIPproxy server. To detectsuchattacks,theALAS

mustmonitoreachURI independently. During anobservationperiod,theURI is extracted

from INVITE andOK messagesandis storedin a trackingtablewithin thesensor. Each

URI entryhasa counterto trackthenumberof INVITEs andOKs observed.At theendof

thesamplingperiod,ALAS checksif any of theURI counterexceedsa chosenthreshold

to decidewhetheranattackis detected.

Upondetectinganattacktargeting a specificURI, ALAS notifiestheSIPProxyvia a

controlmessagethatcontainsa severity indicator. TheSIPproxy will theninitiatean“at-

tackresponse”by returning Temporarily Unavailableor BusyHere messagesto a fraction

of incoming calls to thecorrespondingURI. Theseverity indicatorin thecontrolmessage

determinesthe probability that a new incoming call will be allowed to passthroughthe

proxy. In theworst casescenario,all calls to theURI will beblockedby theproxy. The

call restrictionsareonly removedwhenALAS instructstheproxy to doso.

Insteadof placing the ALAS in front the SIP Proxy, it is possibleto placeit behind

asshown in Figure5.1. However, this will changethe traffic characteristicsseenby the

sensor. During an attack,the responsemechanismin the SIP proxy may be activatedto

rejecta fractionof incomingcalls.As a result,thesensorwill fail to seeall incomingcalls

to updatethe trackingtablecorrectly. It is possibleto inform the sensorwhich calls are

blockedat theproxyby modifying theinteractionbetweentheproxyandsensor, but this is

thescopeof futurework.

55

Enterprise DMZ

Transport Layer Attack "Sensor #SIP

#Redirect

Proxy

SIP #

Registrar / Location Server #

Web $

Server #DNS

Server #

Internal Firewall

Application Layer Attack "Sensor # External

Firewall

Figure5.1: ALAS placedbehindtheSIPProxy.

Theoverheadincurredby monitoring individual URIs is justifiedbecauseit allows the

responsemechanismto targetonly thoseURIs affectedby theattack.Usinganaggregate

basedapproach,e.g.,keepingoneaggregatecounterfor all URIs, would result in all end

terminalsbeingaffectedby theresponsemechanismsif anattackwasdetected.

5.3.2 Transport Layer Attack Sensor (TLAS)

A TLAS is usedto monitorTCPSYN andACK packetsto identify attackstargetedat

the transport/network layer. The pair of SYN andACK packetscanbe usedto detectan

attackbecauseof severalreasons.First,theexternalfirewall is astatefuldeviceandwill not

allow ACK packetsnot associatedwith anexisting connectionto pass.The resultof this

is that anattacker cannotflood a target with a mixtureof bothSYN andACK packetsin

anattemptto hidetheattackfrom theTLAS sincetheACKs will not traversethefirewall.

Secondly, it is relatively difficult for an attacker to spoof the sourceaddressof a SYN

packet andthengeneratea correctACK packet becausethe SYN-ACK packet generated

by thetargetedenterpriseserver will besentto thespoofedaddress.Theattackermight be

56

ableto view theSYN-ACK packet if they werelocatedon thedatapathbetweenthetarget

andthespoofedaddress,but this situationis rare.

Using the SYN and ACK pair also allows for a short observation period. The time

betweenthetwo packetsis equalto theroundtrip timebetweentheenterpriseserverandthe

initiating machine.In theworstcase,this valuewould beon theorderof severalseconds.

This closetime proximity betweenpacketsallows the sensorto usea short observation

periodanddetectanattackquickly.

The locationof the TLAS within the network canbe leveragedto provide protection

to all machinesin theDMZ. TrackingtherelatedSYN andACK packetsat an individual

connectionlevel or endterminalis notappropriatebecauseof theextremelylargevolumeof

connectionsandthelackof trustworthinessof sourceaddresses.Furthermore,DoSattacks

targetingthenetwork layerof adeviceusuallyrequirea largevolumeof traffic. Therefore,

monitoring at an aggregate level is sufficient to detectanomalyduring the presenceof a

network attack.

Theresponsemechanismsfor a transportlayerattackcanbeclassifiedinto threecate-

gories:endserver response,firewall responseandrouterresponse.At theendserver SYN

cache[34] or SYN cookies[9] canbe usedto reducethe amountof resourcesconsumed

by anincoming SYN packet. Ratelimi ting at thefirewall canbeactivatedto decreasethe

frequency of incomingSYN packetsto theservers.Finally, PushbackandAggregateCon-

gestionControl[36, 19] canbeusedby upstreamprovidersto dropoffending flowsbefore

they reachanenterprisenetwork’s border.

5.3.3 ALAS for PSTN Originated Attacks

In aconvergednetwork, it is possibleto launchanattackfrom thePSTN.It is, however,

moredifficult thanattackslaunchedfrom theInternet,becausea largenumberof individ-

ual phonesmustbemarshaledandtheattackmustbecoordinatedbetweena largenumber

of individuals. Nevertheless,provision mustbemadeto detectandcontrol suchflood at-

57

PSTN

Media / Signal

Gateway

Application Layer Attack Sensor

Softphone IP Phone

Enterprise LAN

Authentication %

Server

Figure5.2: DetectingPSTNBasedDoSAttacks

tacks.To detectandcontrolsuchattacks,anALAS canbedeployedin serieswith theMSG

(Figure5.2). A sensorplacedherewould operatealmostidentically to oneplacedbehind

theSIPProxy5.3.1.Thedifferencebetweenthetwo deploymentlocationsis theresponse

mechanismsthat are utilized. For PSTN basedattacks,the MSG must generateTrans-

fer Controlled(TFC) messagesor ReleaseBusymessagesfor thetargetedE.164numbers

dependingon theseverity of theattack[47].

5.3.4 RTP Stream Attack Sensor (RSAS)

A RSASis designedto detectattacksusingmaliciousRTP streamsto saturatetheen-

terprisenetwork. After successfully initiating a call to a victim, the attacker can either

sendvery large RTP packetsor increasethe transmissionrateto hoardthe link capacity.

RSAScaneitherpolice individual streamflow or leveragestatisticaltechniquesto detect

largeflows. In thefirst approach,a protocolparsercanextract codecsandbandwidth re-

quirementsof eachcall upon call setup. This information is provided to RSAS.RSAS

monitors thedataratefor eachindividualRTPstream,andidentify themaliciousflowsthat

58

exceedits stipulatedlimit. Sincean RTP streamin IP Telephony is typically very small

(8-64kbps),statisticalmarkingtechniquesusedin [16] to identify big RTPstreamscanbe

leveraged.Oncea maliciousstreamis detected,thepacketscanbedroppedby thefirewall

immediatelyto preventresourcedepletionof legitimatecalls.

However, neitherof thetwo solutionscanpreventthesaturationof thelink outsidethe

firewall, andonehasto rely on theupstreamrouterto install similar RSASandresponse

mechanism.

5.4 Design of ALAS

Studiesof TCP traffic suggeststhat the averagesessionlength is between12 and19

seconds[64]. Enterprisetelephony traffic, however, lastsmuchlongerandis typically in

theorderof minutes.Studiesreportedin [62] show thatupto 10%of thecall haveduration

over 10 minutes. This differencein sessionlengthsimposesrestrictionson the sampling

schemesthatcanbeusedto detectanimpendingattack.UndernormalIP telephony oper-

ation,thenumberof initiatedhandshakesshouldbevery closeto thenumberof complete

handshakeswithin afixedobservationperiod.A key characteristicof applicationlayerDoS

attackis that thehandshakingprocesswill not becompleted.Therefore,if thedifference

betweenthenumberof initiatedandcompletedhandshakessuddenlybecomesvery large,

it is strongindicationthat the systemis underattack. An additionalbenefitof usingthe

handshakesto detectattacksis the temporalproximity of the messages.This allows for

shortersamplingperiodsandhencelowerdetectiontime.

5.4.1 Detection Algorithm

The algorithmusedin detectingthe presenceof an attackis basedon the work pre-

sentedin [67]. Thecorrelation betweenthenumberof connectionestablishmentattempts

andthecompletedhandshakesis similar to therelationshipbetweenconnectionsetupand

59

tear-down. Thedifferencecanbemodeledasa stationary, randomprocess.Thesensoris

animplementationof SequentialChangePointDetection[6] scheme.In particular, thede-

tectionof anattackis accomplishedby normalizingthedifferencewith theaveragenumber

of connectionsandapplyingthenon-parametric cumulativesummethod[8].

At the end of eachobservation period &�' , (*) is calculatedto be the numberof es-

tablishmentattempts( +-,/.1032 ) minusthe numberof completedhandshakes( 465�.1032 ). To

remove thedependency betweenthemeanof (7) andthesamplesize,a normalizedvalue8 ) is calculatebasedon (7):9<;= where ;= is theaveragenumberof connectionsduringthe

observationperiod&�' . ;= is definedas:

;= .1032 �?> ;= .10A@ � 2�B?. � @ > 2C4D5�.1032 (5.1)

Thedetectionof anattackwithin asingleobservationperiodis basedupontheexpected

valueof8 ) . Undernormaloperation,+E. 8 )F2 �HGEI � . To make detectioneasy, a value

� is chosensuchthat �*JKG and ;8 ) � 8 )L@ � . By shifting8 ) , whenever ;8 ) is positive it

indicatesthepresenceof anattack.

To ensurethat short high volume attacksas well as longer low volume attacksare

detectedby thesensors,thealgorithmincludesacumulativesumcomponent.WedefineMN)as

M ) � MN)NOQPRB ;8 )TSVUXWY.1MN)NOQP�B ;8 ):2 JZZ S [�\^]`_badc7UXef_

(5.2)

If MN) this valueexceedsa pre-definedthresholdvalue, � , the systemis consideredto be

underattack.

5.4.2 Recovery Algorithm

The impact of an attackcan be amplified if it takes a long time to resumenormal

operationoncetheattackhasceased.Threedifferentrecovery algorithmswereconsidered

in this study.

60

Linear Recovery: This algorithmis thedefault behavior of thedetectionalgorithm once

theattackhasstopped.Thevalueof ;8 ) is closeto @ � andthus MN) linearly decaysto Z . If

thevalueof MN) is largewhentheattackceasesandtheoffset, � , is small, it will requirea

long time for MN) to dropbelow thethreshold� . This resultsin theresponsemechanismsto

remainactivatedfor gfhi minutesaftertheattackis over. Notethattheunderlyingassumption

is that, thesensorobservesunfiltereddata,i.e., thesensoris placebetweentheSIPproxy

serverandtheexternalfirewall.

Exponential Recovery: In this recovery algorithm, Mj) is decrementedusinga multiplica-

tive factoronce ;8 )/k Z . Thevalueof MN) is calculatedby:

MN) � MN)NO`P�B ;8 ):S�UXWl;8 ) JZMN)NO`Pm@ � � S [�\^]`_badc7UXeC_

If ;8 )on Z , thevalueof p is incrementedafter MN) is calculated.OnceMN) returnsto Z or

beginsto increase,thevalueof p is resetto � . Usingthis approach,thetime for which the

attackresponsemechanismremainsactiveaftertheattackhasceasedis qX[Nr i .1MN):2 minutes.

Reset after Timeout: Thisschemeis anextensionof thelinearrecoveryalgorithm. When

thevalueof MN) begins to drop,a timer, + , is started.Thevalueof MN) is allowedto decay

linearlyuntil thetimerexpires.At theexpiration of thetimer, if thevalueof Mj) is still above

thethreshold� , it is resetto Z . Unliketheothertwo approaches,by usingdiscretetimeouts

it is possibleto placeafixedupperbound,+ , on thetime theresponsemechanismswill be

in placeaftertheattackhasstopped.

5.5 Quantitative Analysis of ALAS

To ensuretheapplicationlayersensoroperatedcorrectly, onewasplacedin thefront of

theDMZ. This guaranteedthatall traffic cominginto andout of theenterprise’s network

wouldpassthroughthesensor. As shown in Figure5.3,it is alsopossibleto placeaNLAS

sensorin serieswith theALAS.

61

Internet

Enterprise DMZ

Transport Layer Attack Sensor

SIP Redirect Proxy

SIP Registrar / Location Server

Web Server

DNS Server

Edge Router

External Firewall

Application �

Layer Attack Sensor

Figure5.3: ALAS Placedwithin theDMZ

5.5.1 DoS Attack Models

To evaluatetheperformanceof ALAS, thefollowing threedifferentDoSscenarioswere

considered.

Limited DoS Attack: This attackinvolvesa singleURI being targetedby oneor more

attackers. The volume of incoming attackcalls is from a low annoyancelevel (of one

hostilecall perminute)to anoverwhelming level (of 10 or morehostilecallsperminute).

Thisattackdoesnotdegradethelevel of servicethroughout theenterprise.

Stealth DoS Attack: This attackinvolvesoneor moreattackerstargetinga largenumber

of URIs. EachURI receives a very low volume of calls (e.g., one per minute or less).

However, in theaggregatethis resultsin ahighusageof network resources.

Aggressive DoS Attack: This attackcanbeviewedasa combinationof thetwo previous

cases.In this attackoneor moreattackers initiate a low volume of calls to a moderate

numberof URIs. The impact of the attackis two fold: 1) the targetedend userswere

successfullydisruptedfrom their normal operationsand2) a largeamountof network re-

sourceswereconsumedcausingotherservicesto suffer.

62

5.5.2 Enterprise User Model

Theusermodeldefiningthedistribution of callsto differentURIsis shown in Table5.1.

The majority of URIs received a very low volumeof calls during the simulation period.

However, therearecertainaddresseswithin anenterprise(e.g.,helpdesk,front office,etc.)

thatreceive a muchhighervolumeof calls. To determineif thevolumeof legitimatecalls

affectedtheperformanceof thesensors,bothhigh andlow volumeuserswereincludedin

themodel.

Table5.1: EnterpriseCall Distribution

Class CallsReceivedDuringSimulation Numberof URIsA 1 500B 2 - 5 400C 6 - 10 80D 11 - 20 20

5.5.3 Simulation Parameters

Eachsimulation run lastedthirty minuteswith the detectionalgorithm samplingthe

traffic andcalculatingstatisticseachminute.For eachrecovery algorithm,two simulation

experimentswere conductedwith limited DoS attacksusing 4 and 10 hostile calls per

minute to a single URI. To ensurethat ALAS would detectthe attackregardlessof the

volume of legitimatecalls, two URIs were targetedduring eachsimulation. Oneof the

URIs received 2 to 5 calls during the simulationperiodand the other received up to 20

calls. The attackswereeach5 minutes in lengthandstartedon the secondandseventh

minuteof thesimulation.

Two additional simulationsuseda stealthDoS attackandan aggressive DoS attack,

respectively. Thestealthattacktargeted200uniqueURIs out of the1000URIs within the

enterpriseandgeneratedonecall aminuteto eachURI. Theaggressiveattackonly used50

uniqueURIs, with 3 callsminuteto eachtarget. Theattackslasted10 minutesandbegan

63

s tuvw xyz{|ts

t v x z}| t t~t v t x�t z t |utuvuxuzu|�� d��

� ��

� � � � ¡ ¢ £ ¤ ¥ ¦¨§ ¥ © ª « ¬� ® ¯� � � � ¡ ° £ ± ² ³ ´ § ¥ © ª « ¬� ® ¯

µ¶· µ· ¶¸�µ¸ ¶¹�µ¹ ¶º�µ

·»¹ ¶½¼¿¾ ·�·À· ¹�· ¶ · ¼ · ¾ ¸¨·Á¸�¹~¸ ¶ ¸ ¼ ¸ ¾Â�Ã ÄdÅdÆ Ä�Ã Ç�È É Å Ê�Ë

Ì ÍÎ Ï ÐÎ ÍÑ ÒÓÔ ÍÎ ÐÒÕÖ× Ø

Ù Ú Ú Û Ü Ý Þ ß à á â¨ã á ä å æ ç�è é êÙ Ú Ú Û Ü Ý ë ß ì í î ï ã á ä å æ ç�è é ê

(a) Linear Recovery with 4 attackcalls perminute

(b) Linear Recovery with 10 attackcalls perminute

ðñò ðò ñó ðó ñô ðô ñõ ðõ ñ

ò¿ôöñ½÷öøùò ò?ò ôúò ñúò ÷úò øûó òüó ôó ñó ÷ó øý þ ÿ�� ÿ1þ � � � � � �

� � � � ��

� � � � � � � � � � �! � " # $ %'& ( )� � � � � � * � + , - . � " # $ %'& ( )

/

0

1 /

1 0

2 /

2 0

3 /

3 0

4'/

15360676891 1:1 3;1 0;1 7;1 8:2<1=2 3:2 0:2 7:2 8>@? ACBCD AE? F<G H B I'J

K LM NOM LP QR LM OQSTUV

W X X Y Z [<\ ] ^ _ `ba _ c d e<f�g h iW X X Y Z [ j<] k l m n'a _ c d e<f�g h i

(c) ExponentialRecoverywith 10attackcallsperminute

(d) Resetafter Timeoutwith 10 attackcallsperminute

Figure5.4: IndividualURI DetectionusingLimited DoS( �� and� ��m� )

on thesecondminuteof thesimulation.

Theoffsetvalues,� �� and � �� , weresetto 2 and1, respectively. Theattackthresholds,

� �� and � �� , weresetto 5 and2. Thevalue + for thediscretetimeout algorithmwasset

to 2.

5.5.4 Experimental Results

Two key metricswereusedto determine its performance: attackdetectiontime and

systemrecovery time. Figure 5.4 shows the sensor’s detectionof a limited DoS attack

64

o

o'p q

r

r p q

s

s'p q

t

t'p q

rutvq6wvx9r ryr t;r q;r wzr x:s<r{s tys q:s wys x|@} ~�� ~C} �'� � � � �

� ��

� �� '� � � �<�<� ¡ ¡ �'¢ £ ¤ ¥<� ¦ § � £

¨

©

ª

«

¬

®

¯

°

©v«±²¯²³´© ©;© «µ© ¶© ¯µ© ³;ª<©:ª «·ª ;ª ¯;ª ³¸�¹ º�»�¼ ºC¹ ½'¾ ¿ » À Á

Â ÃÄ ÅÆÄ ÃÇ ÈÉÊ ÃÄ ÆÈËÌÍÎ

Ï Ð Ð�Ñ Ò Ó Ô Õ Ö × Ø@Ù Ú Û Ü Ü Ý Þ ß à<Ö á â × Þ

(a)AggressiveDoSAttack (b) StealthDoSAttack

Figure5.5: AggregateLevel Detection( ��H� and� �� )

at the individual URI level. Figure 5.5 shows the detectionplots at the aggregate level

for the aggressive andstealthDoS attacks. By choosingthe offset and thresholdvalues

appropriately, the falsealarmratewasreducedto zerofor all simulations. Lowering the

valueswould allow for morestealthierattacksto bedetected,but would alsoincreasedthe

falsealarmrate.

Theattackdetectiontimesfor thefour DoSattackstypesareshown in Table5.2. The

resultsin Figures5.4and5.5show thatthelargerthevolumeof attackcalls,theshorterthe

detectiontime. Theoneresultthatmight seemsurprisingis thestealthattackwasdetected

in lesstime thantheaggressive attack.This is becausetheoverall call volume wasgreater

for the particularstealthandaggressive attacksusedin this study. The aggressive attack

generated150 attackcalls per minute(threecalls to 50 differentURIs) while the stealth

generated200attackcallsperminute (onecall to 200differentURIs).

Table5.2: DoSAttackDetectionTime

AttackType DetectionTime4 calls/minLimited DoS 4 minutes(URI level)10calls/minLimited DoS 2 minutes(URI level)50URI AggressiveDoS 6 minutes(URI level)

8 minutes(aggregatelevel)200URI StealthDoS 4 minutes(aggregatelevel)

65

To evaluatetheperformanceandimpactof thedifferentrecovery algorithms,a limited

DoStargetinga low volumeURI wasused.Table5.3 shows theamountof time required

from theendof theattackuntil thelevelsin thesensordroppedbelow thethreshold.Figures

5.4b,5.4cand5.4dprovideagraphicalrepresentationof therecoveryalgorithmsoperation.

As expected,the linear recovery algorithmperformancewassubstantiallylower thanthe

other two. For real world deployments,the increasein sensorcomplexity to usethe ex-

ponentialor resetafter timeoutalgorithms is acceptablebecauseof the greatincreasein

performance.Thecostof usinga poorperforming recovery algorithmis substantialif the

responsemechanismsremainactivatedmuchbeyondtheendof theattack.

Table5.3: RecoveryTime for Limited DoSonLow VolumeURI

AttackVolume- RecoveryAlg. RecoveryTime4 calls/min- LinearRecovery 3 minutes10calls/min- LinearRecovery 17minutes

10calls/min- ExponentialRecovery 6 minutes10calls/min- ResetafterTimeout 3 minutes

To ensurethat thedetectionalgorithmworks independentof thevolumeof legitimate

traffic receivedby any URI, two limitedattackstargetingtwo URIs from differentusercat-

egoriesin Table5.1 wereconsidered.For userswith a high volume of legitimatetraffic,

thevalue ;= . 032 in Equation5.1 is large. This impactsthenormalizationof thedifference

betweenconnectionattemptsandestablishments.Thelargerthevalueof ;= . 032 , thegreater

in reductionof8 ) because

8 ) � (7):9 ;= .1032 . Figure5.4bshows the impactof this nor-

malization.Thepeakvalueof theattackon thehigh volumeURI is 25%lessthanthelow

volumeURI target.

66

Chapter 6

Summary

Thedeploymentof IP telephony andotherdynamicapplications will allow enterprises

to becomemore cost effective and offer a higher level of integration. However, before

wide spreadadoptioncanplaceseveralmajorobstaclesmustbeovercome.It wasshown

that dynamicapplicationscannotfunction properly when operatingover static network

devices.Previouswork hasprovidedlimited solutionsthatonly addresssingleissues.The

SecureTelephony EnabledMiddlebox (STEM) architecturepresentedin this work is a

comprehensivesolutionto theproblem.

The STEM architecturewasdesignedto be technologicallyneutral,therebyallowing

it to work in a diverserangeof network environments.Ensuringthe securityof the net-

work wasa top priority in the STEM architecture.Major network-basedvulnerabilities

presentin an IP telephony deploymentwereenumeratedandthe impactswerediscussed.

A completeprotectionframework wasoutlined to addressall of themajorclassesof vul-

nerabilities.TheSecureIP Telephony usingMulti-layeredProtection(STUMP)framework

usesacombinationof existing andnew technologyto ensureoverall network security.

A detailedexaminationof DoS attacksagainst IP telephony enabledenterprisenet-

worksshowedthata largeclassof attackscanonly behandledby implementing dedicated

sensorsin enterprisenetwork. The operationandimplementation of sensorsat the trans-

67

port and applicationlayerswere describedin detail. Eachof thesesensorsexploited a

non-parametric cumulative sumalgorithmto detectthepresenceof anattack. In addition

to attackdetection,theimpactandperformanceof threedifferentrecoveryalgorithmswere

examined. A quantitative analysisusinga simulatedenterpriseenvironment showed that

the detectionalgorithm correctly identified threedifferent typesof DoS attacksandthat

therewasdifferencesbetweenthedifferentrecoveryalgorithms.

6.1 Future Work

With thedesignof thearchitecturecomplete,thecreationof a completeprototype net-

work usingtheSTEM architecturewith theSTUMPoverlayframework overlaidis thenext

step.A prototypewould allow experimentalvalidationof thesecurityandfunctionality of

the architecture.Furthersimulation configurationsof the two DoS sensorsdevelopedis

alsoneeded.The impactof the variousparametersandtheir interactionwith the perfor-

manceof thesensors.Finally, theflow monitorconceptneedsfurtherrefinementbeforeit

canbeimplementedandtested.

68

Appendix A

List of Publications & Presentations

A.1 Publications

� B. ReynoldsandD. Ghosal,”STEM: SecureTelephony EnabledMiddlebox”, in IEEE

Communications, vol. 40,no. 10,Oct. 2002.

� B. ReynoldsandD. Ghosal,”DefendingAgainstAttack in ConvergedNetworks”, in

Proceedingsof the2002UC DavisStudentWorkshoponComputing, Davis, Oct. 2002.

� B. ReynoldsandD. Ghosal,”SecureIP Telephony usingMulti-l ayeredProtection”,

to appearin Proceedingof NetworkandDistributedSystemSecuritySymposium(NDSS),

SanDiego,Feb. 2003.

� B. Reynolds, D. Ghosal,C. Chuahand S. F. Wu, ”Vulnerability Analysis and A

SecurityArchitecturefor IP Telephony”, submittedto OpenArchitectures and Network

Programming(OPENARCH), SanFrancisco,Apr. 2003.

A.2 Presentations

� ”ChallengesandRewardsin EnterpriseDeploymentof IP Telephony”, Network Lab

Seminar, Universityof California atDavis (Mar. 2002).

69

� ”Deploying IP Telephony in anEnterpriseandtheVulnerabilities thatComeWith It”,

SecurityLabSeminar, Universityof California atDavis (July 2002).

70

Bibliography

[1] estara- pushto talk. World WideWeb,http://www.estara.com/, 2002.

[2] The linux documentationproject. World Wide Web,http://www.tldp.org/,2002.

[3] Netfilter - firewalling, NAT, andpacket mangling for Linux 2.4. World Wide Web,http://www.netfilter.org/, 2002.

[4] Vovida.org - your sourcefor opensourcecommunication. World Wide Web,http://www.vovida.org/, 2002.

[5] M. Barnes. Internet draft: MIDCOM protocol evaluation, May 2002. Work inProgress.

[6] M. Basseville andI. V. Nikif orov. Detectionof AbruptChanges: TheoryandAppli-cation. PrenticeHall, 1993.

[7] Baugher, McGrew, Oran,Blom, Carrara,Naslund,andNorrman. Internetdraft: Thesecurerealtime transportprotocol, May 2002.Work in Progress.

[8] B. E. Brodsky andB. S.Darkhovsky. NonparametricMethodsin ChangepointProb-lems. Kluwer AcademicPublishers,1993.

[9] Bronzesoft.org. SYN cookies firewall. World Wide Web, http://www.bronzesoft.org/projects/scfw, 2002.

[10] J.BurnsandD. Ghosal.Designandanalysisof anew algorithm for automaticdetec-tion andcontrol of mediastimulatedfocusedoverloads. In Proceedingsof Interna-tional Teletraffic Congress, Edinburgh, June1997.

[11] CERT Coordination Center. CERT Advisory CA-1996-21:TCP SYN flooding andIP spoofingattacks,November2000.

[12] William CheswickandSteven Bellovin. Firewalls and InternetSecurity. AddisonWesley Longman,Inc.,New York, NY, 1stedition,1994.

[13] K. Claffy, G. Polyzos,and H. Braun. Application of samplingmethodologies tonetwork traffic characterization.In Proceedingsof ACM SIGCOMM, SanFrancisco,September1993.

71

[14] R. DanielandM. Mealling. RFC2168: Resolutionof Uniform ResourceIdentifiersusingtheDomainNameSystem,June1997.

[15] T. DierksandC. Allen. RFC2246:TheTLS Protocol,January1999.

[16] C. EstanandG. Varghese.New directionsin traffic measurementandaccounting.InProceedingsof ACM SIGCOMM, Pittsburg, August2002.

[17] P. Faltstrom.RFC2916:E.164numberanddns,September2000.

[18] R.Fielding,J.Gettys,J.Mogul,H. Frystyk,andT. BernersLee.RFC2068:HypertextTransferProtocol– HTTP/1.1,January1997.

[19] Sally Floyd andVan Jacobson.RandomEarly DetectionGatewaysfor CongestionAvoidance.IEEE/ACM TransactionsonNetworking, 1(4):397–413,August1993.

[20] A. Garg andA. Reddy. Mitigation of dosattacksthroughqosregulation.In Proceed-ingsof IEEE InternationalWorkshopon Quality of Service(IWQoS), Miami Beach,May 2002.

[21] ITU-T Recommendation H.323. Visual telephonesystemsandequipmentfor localareanetworkswhichprovideanon-guaranteedqualityof service,May 1996.

[22] M. Handley andV. Jacobson.RFC2327: SDP:SessionDescriptionProtocol,April1998.

[23] M. Handley, H. Schulzrinne,E. Schooler, andJ.Rosenberg. RFC2543:SIP:SessionInitiationProtocol,March1999.

[24] IEEE. Middlebox communication (midcom)charter. World Wide Web,http://www.ietf.org/html.charters/midcom-charter.html, 2002.

[25] IEEE. Sessioninitiationprotocolinvestigation (sipping) charter. World Wide Web,http://www.ietf.org/html.charters/sipping-charter.html,2002.

[26] IEEE. Session initiation protocol (sip) charter. World Wide Web,http://www.ietf.org/html.charters/sip-charter.html, 2002.

[27] Universityof SouthernCaliforniaInformation SciencesInstitute. RFC791: InternetProtocol,September1981.

[28] J. IoannidisandS. Bellovin. Implementingpushback:Router-baseddefenseagainstDDoS attacks. In Proceedingsof Networkand DistributedSystemSecuritySympo-sium, SanDiego,February2002.

[29] J. Jedwab, P. Phall, and B. Pinna. Traffic estimationfor the largestsourceson anetwork, usingpacket samplingwith limi tedstorage.TechnicalReport35, HewlettPackardLabs,March1992.

72

[30] A. Johnston,S. Donovan, R. Sparks,C. Cunningham, D. Willis, J. Rosenberg,K. Summers,andH. Schulzrinne.Internetdraft: SIPcall flow examples,April 2002.Work in Progress.

[31] A. Karim. H.323andassociatedprotocols,2000.

[32] J. Kohl andC. Neuman.RFC1510: TheKerberosNetwork AuthenticationService(V5), September1993.

[33] J. Kuthan. Internet telephony traversalacrossdecomposedfirewalls andNATs. InProceedingsof the2ndIP TelephonyWorkshop, New York, April 2001.

[34] J. Lemon. ResistingSYN flood DoS attackswith a SYN cache. In ProceedingsofUSENIXBSDCon2002, SanFrancisco,February2002.

[35] V. Mahadig. Detection of denial-of-QoS attacksbasedon chi squarestatisticandewma control charts. world Wide Web,http://arqos.csc.ncsu.edu/papers/2002-02-usenixsec-diffservattack.pdf, February2002.

[36] R. Mahajan,S.Bellovin, S.Floyd, J.Vern,andP. Scott. Controlling high bandwidthaggregatesin thenetwork. TechnicalReport1, University of California, Berkeley -InternationalComputerScienceInstitute,February2001.

[37] C. Perkins.RFC2002:IP Mobility Support,October1999.

[38] J. Peterson.Internetdraft: A privacy mechanismfor thesessioninitiation protocol,May 2002.Work in Progress.

[39] J.Postel.RFC768: UserDatagramProtocol,August1980.

[40] J.Postel.RFC793: TransmissionControlProtocol,September1981.

[41] N. Provos. Vomit - voiceover misconfiguredinternettelephones.World Wide Web,http://vomit.xtdnet.nl/, 2001.

[42] C. Rigney, S.Willens,A. Rubens,andW. Simpson.RFC2865:RemoteAuthentica-tion Dial in UserService(RADIUS), June2000.

[43] U. Roedig,R. Ackermann,andR. Steinmetz.Evaluatingandimproving firewalls forIP-telephony environments. In Proceedingsof the1stIP TelephonyWorkshop, Berlin,April 2000.

[44] J. Rosenber, J. Weinberger, andH. Schulzrinne. Internetdraft: SIP extensionsforNAT traversal,November2001.Work in Progress.

[45] J. Rosenberg andH. Schulzrinne.RFC2871: A Framework for Telephony Routingover IP, June2000.Status:Informational.

[46] J. Rosenberg, H. Schulzrinne,G. Camarillo, A. Johnston,J. Peterson,R. Sparks,M. Handley, andE.Schooler. Internetdraft: SIP:Sessioninitiationprotocol, February2002.Work in Progress.

73

[47] Travis Russell.SignalingSystem7. McGraw-Hill, New York, NY, 3rdedition,2000.

[48] Travis Russell. TelecommunicationsProtocols. McGraw-Hill, New York, NY, 2ndedition,2000.

[49] E. Schooler. A multicastuserdirectoryservicefor synchronousrendezvous.Master’sthesis,Departmentof ComputerScience,California Instituteof Techonology, August1996.

[50] H. Schulzrinne,S.Casnet,R. Frederick,andV. Jacobson.RFC1889:RTP: A Trans-portProtocolfor Real-TimeApplications,January1996.

[51] H. SchulzrinneandS.Petrack.RFC2833:RTP payloadfor DTMF digits, telephonytonesandtelephony signals,May 2000.

[52] H. Schulzrinne,A. Rao,andR.Lanphier. Internetdraft: Realtimestreamingprotocol,February2002.Work in Progress.

[53] HenningSchulzrinneandJonathanRosenberg. A Comparisonof SIPandH.323forInternetTelephony.

[54] HenningSchulzrinneand JonathanRosenberg. Signaling for InternetTelephony,1998.

[55] HenningSchulzrinneandJonathanRosenberg. InternetTelephony: ArchitectureandProtocols- anIETF Perspective. ComputerNetworks, 31(3):237–255,1999.

[56] P. Srisuresh,J. Kuthan,J. Rosenberg, A. Molitor, and A. Rayan. InternetDraft:Middlebox communication architectureand framework, December2001. Work inProgress.

[57] P. Srisuresh,J.Kuthan,J.Rosenberg, A. Molitor, andA. Rayhan.Internetdraft: Mid-dleboxcommunicationarchitectureandframework,February2002.Work in Progress.

[58] A. StephensandP. Cordell. SIPandH.323- interworkingVoIPnetworks,2001.

[59] RichardStevens. TCP/IP IllustratedVolume1: TheProtocols, volume 1. AddisonWesley Longman,Inc.,Reading,MS, 1stedition,1994.

[60] R. Swale, P. Mart, P. Sijben, S. Brim, and M. Shore. InternetDraft: Middleboxcommunciationsprotocolrequirements,November2001.Work in Progress.

[61] R. Swale,P. Mart, P. Sijben,S.Brim, andM. Shore.Internetdraft: Middleboxcom-municationsprotocolrequirements,November2001.Work in Progress.

[62] Telecost.Enterprisecall durations distributions. World Wide Web,http://www.telecost.co.uk/pages/OnCallDurations.htm, 2002.

[63] R. Thayer, N. Doraswamy, and R. Glenn. RFC 2411: IP Security DocumentRoadmap,November1998.

74

[64] K. Thompson,G. J. Miller, andR. Wilder. Wide-areainternettraffic patternsandcharacteristics.IEEENetwork, 11(6),December1997.

[65] Johnvan Bosse. Signaling in TelecommunicationNetworks. JohnWiley & Sons,New York, NY, 1stedition,1998.

[66] F. Wang,F. Gong,andF. S.Wu. Propertyorientedfault detectionfor link statebasedrouting protocols. In Proceedingsof IEEE International Conferenceon CompterCommunicationsandNetworks, LasVegas,October2000.

[67] H. Wang,D. Zhang,andK. Shin. DetectingSYN floodingattacks.In ProceedingsofIEEE INFOCOM2002, New York, June2002.

[68] D. Yau,J. Lui, andF. Liang. Defendingagainstdistributeddenial-of-serviceattackswith max-min fair server-centric router throttles. In Proceedingsof IEEE Interna-tional WorkshoponQualityof Service(IWQoS), Miami Beach,May 2002.

[69] W. Yeong,T. Howes,andS.Kille. RFC1777:LightweightDirectoryAccessProto-col, March1995.

Documents

Enabling Secure IP Telephony in Enterprise Networks By … · 2005-03-23 · Enabling Secure IP Telephony in Enterprise Networks By BRENNEN EMERICK REYNOLDS B.S. (University of California,