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
Calling Terminal userA@domain1
Called Terminal userB@domain3
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
Media flow over RTP using dynamic UDP ports
BYE From, To, Call-ID, CSeq, Via
200 OK
INVITE (userB@domain2)
Redirect Server
moved Contact: userB@domain3
ACK �
Figure2.5: SIPRedirectCall Model
Calling Terminal userA@domain1
Called Terminal userB@domain2
Media flow over RTP using dynamic UDP ports
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
Media flow over RTP using dynamic UDP ports
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 SIP Endpoint
External Firewall
SIP Redirect Server
Internal SIP Endpoint
TCP SYN (1)
INVITE (8) Trying (9)
Ringing (11) Unavailable (12)
TCP SYN - ACK (2) TCP ACK (3)
INVITE (4) TCP SYN (5)
TCP ACK (7) TCP SYN-ACK (6)
Trying (10) Ringing (11)
Unavailable (15)
(b) CalledParty is Busy
Figure3.5: IncomingNet-to-NetCall Flows - Part 1
31
External SIP Endpoint
External Firewall
SIP Redirect Server
Mobile IP Home Agent
INVITE (9)
Ringing (11)
OK (12)
Call Established (15) (RTP Data Flow)
BYE (16)
INVITE (4) Trying (5)
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 SIP Endpoint
External Firewall
SIP Redirect Server
Internal SIP Endpoint
TCP SYN (1)
INVITE (9) Trying (10)
Ringing (11)
TCP ACK (3) INVITE (4)
TCP SYN (6)
TCP ACK (8) TCP SYN-ACK (7)
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 SIP Endpoint
External Firewall
SIP Redirect Server
Internal SIP Endpoint
TCP SYN (1)
INVITE (9) Trying (10)
Ringing (11)
TCP ACK (3) INVITE (4)
TCP SYN (6)
TCP ACK (8) TCP SYN-ACK (7)
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
Media / Signal Gateway
SIP Endpoint
SETUP (1) IAM (2)
REL No Avaiable Circuits (3)
RLC (5) RELEASE (6)
RELEASE COMPLETE (7)
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
Media / Signal Gateway
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)
RELEASE COMPLETE (17)
RLC (16)
OK (13) BYE (12)
Trying (2)
ACK (10)
Call Established (11) (Voice)
(a)Successful
PSTN Endpoint
Terminating Local Exchange
Media / Signal Gateway
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.