RFC 5853 - Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC)...

5/5/2015 RFC5853RequirementsfromSessionInitiationProtocol(SIP)SessionBorderControl(SBC)Deployments

https://tools.ietf.org/html/rfc5853 1/52

InternetEngineeringTaskForce(IETF)J.Hautakorpi,Ed.RequestforComments:5853G.CamarilloCategory:InformationalEricssonISSN:20701721R.PenfieldAcmePacketA.HawrylyshenSkype,Inc.M.Bhatia3CLogicApril2010

RequirementsfromSessionInitiationProtocol(SIP)SessionBorderControl(SBC)Deployments

Abstract

ThisdocumentdescribesfunctionsimplementedinSessionInitiationProtocol(SIP)intermediariesknownasSessionBorderControllers(SBCs).ThegoalofthisdocumentistodescribethecommonlyprovidedfunctionsofSBCs.AspecialfocusisgiventothosepracticesthatareviewedtobeinconflictwithSIParchitecturalprinciples.Thisdocumentalsoexplorestheunderlyingrequirementsofnetworkoperatorsthathaveledtotheuseofthesefunctionsandpracticesinordertoidentifyprotocolrequirementsanddeterminewhetherthoserequirementsaresatisfiedbyexistingspecificationsorifadditionalstandardsworkisrequired.

StatusofThisMemo

ThisdocumentisnotanInternetStandardsTrackspecification;itispublishedforinformationalpurposes.

ThisdocumentisaproductoftheInternetEngineeringTaskForce(IETF).ItrepresentstheconsensusoftheIETFcommunity.IthasreceivedpublicreviewandhasbeenapprovedforpublicationbytheInternetEngineeringSteeringGroup(IESG).NotalldocumentsapprovedbytheIESGareacandidateforanylevelofInternetStandard;seeSection2ofRFC5741.

Informationaboutthecurrentstatusofthisdocument,anyerrata,andhowtoprovidefeedbackonitmaybeobtainedathttp://www.rfceditor.org/info/rfc5853.



Hautakorpi,etal.Informational[Page1]



RFC5853RequirementsfromSIPSBCDeploymentsApril2010

CopyrightNotice

Copyright(c)2010IETFTrustandthepersonsidentifiedasthedocumentauthors.Allrightsreserved.

ThisdocumentissubjecttoBCP78andtheIETFTrust'sLegalProvisionsRelatingtoIETFDocuments(http://trustee.ietf.org/licenseinfo)ineffectonthedateofpublicationofthisdocument.Pleasereviewthesedocumentscarefully,astheydescribeyourrightsandrestrictionswithrespecttothisdocument.CodeComponentsextractedfromthisdocumentmustincludeSimplifiedBSDLicensetextasdescribedinSection4.eoftheTrustLegalProvisionsandareprovidedwithoutwarrantyasdescribedintheSimplifiedBSDLicense.




TableofContents

1.Introduction....................................................42.BackgroundonSBCs..............................................42.1.PeeringScenario...........................................62.2.AccessScenario............................................63.FunctionsofSBCs...............................................83.1.TopologyHiding............................................83.1.1.GeneralInformationandRequirements................83.1.2.ArchitecturalIssues................................93.1.3.Example.............................................93.2.MediaTrafficManagement..................................113.2.1.GeneralInformationandRequirements...............113.2.2.ArchitecturalIssues...............................123.2.3.Example............................................133.3.FixingCapabilityMismatches..............................143.3.1.GeneralInformationandRequirements...............143.3.2.ArchitecturalIssues...............................143.3.3.Example............................................153.4.MaintainingSIPRelatedNATBindings......................153.4.1.GeneralInformationandRequirements...............153.4.2.ArchitecturalIssues...............................163.4.3.Example............................................173.5.AccessControl............................................183.5.1.GeneralInformationandRequirements...............183.5.2.ArchitecturalIssues...............................193.5.3.Example............................................193.6.ProtocolRepair...........................................203.6.1.GeneralInformationandRequirements...............203.6.2.ArchitecturalIssues...............................213.6.3.Examples...........................................213.7.MediaEncryption..........................................213.7.1.GeneralInformationandRequirements...............213.7.2.ArchitecturalIssues...............................223.7.3.Example............................................224.DerivedRequirementsforFutureSIPStandardizationWork.......235.SecurityConsiderations........................................236.Acknowledgements...............................................247.References.....................................................257.1.NormativeReferences......................................257.2.InformativeReferences....................................25




1.Introduction

Inthepastfewyears,therehasbeenarapidadoptionoftheSessionInitiationProtocol(SIP)[1]anddeploymentofSIPbasedcommunicationsnetworks.Thishasoftenoutpacedthedevelopmentandimplementationofprotocolspecificationstomeetnetworkoperatorrequirements.Thishasledtothedevelopmentofproprietarysolutions.Often,theseproprietarysolutionsareimplementedinnetworkintermediariesknowninthemarketplaceasSessionBorderControllers(SBCs)becausetheytypicallyaredeployedattheborderbetweentwonetworks.Thereasonforthisisthatnetworkpoliciesaretypicallyenforcedattheedgeofthenetwork.

EventhoughmanySBCscurrentlybehaveinwaysthatcanbreakendtoendsecurityandimpactfeaturenegotiations,thereisclearlyamarketforthem.NetworkoperatorsneedmanyofthefeaturescurrentSBCsprovide,andoftentherearenostandardmechanismsavailabletoprovidethem.

ThepurposeofthisdocumentistodescribefunctionsimplementedinSBCs.AspecialfocusisgiventothosepracticesthatconflictwithSIParchitecturalprinciplesinsomeway.Thedocumentalsoexplorestheunderlyingrequirementsofnetworkoperatorsthathaveledtotheuseofthesefunctionsandpracticesinordertoidentifyprotocolrequirementsanddeterminewhetherthoserequirementsaresatisfiedbyexistingspecificationsorifadditionalstandardsworkisrequired.

2.BackgroundonSBCs

ThetermSBCisrelativelynonspecific,sinceitisnotstandardizedordefinedanywhere.NodesthatmaybereferredtoasSBCsbutdonotimplementSIPareoutsidethescopeofthisdocument.

SBCsusuallysitbetweentwoserviceprovidernetworksinapeeringenvironment,orbetweenanaccessnetworkandabackbonenetworktoprovideservicetoresidentialand/orenterprisecustomers.Theyprovideavarietyoffunctionstoenableorenhancesessionbasedmultimediaservices(e.g.,VoiceoverIP).Thesefunctionsinclude:a)perimeterdefense(accesscontrol,topologyhiding,anddenialofservicepreventionanddetection);b)functionalitynotavailableintheendpoints(NATtraversal,protocolinterworkingorrepair);andc)trafficmanagement(mediamonitoringandQualityofService(QoS)).SomeofthesefunctionsmayalsogetintegratedintootherSIPelements(likeprepaidplatforms,ThirdGenerationPartnershipProject(3GPP)ProxyCSCF(PCSCF)[6],3GPPICSCF,etc.).




SIPbasedSBCstypicallyhandlebothsignalingandmediaandcanimplementbehaviorthatisequivalenttoa"privacyservice"(asdescribedin[2])performingbothHeaderPrivacyandSessionPrivacy).SBCsoftenmodifycertainSIPheadersandmessagebodiesthatproxiesarenotallowedtomodify.Consequently,theyare,bydefinition,B2BUAs(BacktoBackUserAgents).ThetransparencyoftheseB2BUAsvariesdependingonthefunctionstheyperform.Forexample,someSBCsmodifythesessiondescriptioncarriedinthemessageandinsertaRecordRouteentry.OtherSBCsreplacethevalueoftheContactheaderfieldwiththeSBCs'addressandgenerateanewCallIDandnewToandFromtags.

++|SBC|[signaling]|++||signaling|outer|++|innernetwork|||network|++||media|[media]|++|++

Figure1:SBCArchitecture

Figure1showsthelogicalarchitectureofanSBC,whichincludesasignalingandamediacomponent.Inthisdocument,thetermsouterandinnernetworkareusedfordescribingthesetwonetworks.AnSBCislogicallyassociatedwiththeinnernetwork,andittypicallyprovidesfunctionssuchascontrollingandprotectingaccesstotheinnernetworkfromtheouternetwork.TheSBCitselfisconfiguredandmanagedbytheorganizationoperatingtheinnernetwork.

Insomescenarios,SBCsoperatewithusers'(implicitorexplicit)consent;whileinothers,theyoperatewithoutusers'consent(thislattercasecanpotentiallycauseproblems).Forexample,ifanSBCinthesameadministrativedomainasasetofenterpriseusersperformstopologyhiding(seeSection3.1),theenterpriseuserscanchoosetoroutetheirSIPmessagesthroughit.IftheychoosetoroutethroughtheSBC,thentheSBCcanbeseenashavingtheusers'implicitconsent.AnotherexampleisascenariowhereaserviceproviderhasbrokengatewaysanditdeploysanSBCinfrontofthemforprotocolrepairreasons(seeSection3.6).UserscanchoosetoconfiguretheSBCastheirgatewayand,so,theSBCcanbeseenashavingtheusers'implicitconsent.




2.1.PeeringScenario

Atypicalpeeringscenarioinvolvestwonetworkoperatorswhoexchangetrafficwitheachother.AnexamplepeeringscenarioisillustratedinFigure2.Anoriginatinggateway(GWA1)inOperatorA'snetworksendsanINVITEthatisroutedtotheSBCinOperatorB'snetwork.Then,theSBCforwardittothesoftswitch(SSB).Thesoftswitchrespondswitharedirect(3xx)messagebacktotheSBCthatpointstotheappropriateterminatinggateway(GWB1)inOperatorB'snetwork.IfOperatorBdoesnothaveanSBC,theredirectmessagewouldgototheOperatorA'soriginatinggateway.Afterreceivingtheredirectmessage,theSBCsendstheINVITEtotheterminatinggateway.

OperatorA.OperatorB..2)INVITE++./>++|SSA|./3)3xx(redir.)|SSB|++.//++.//++1)INVITE++//++|GWA1|>|SBC|++.++.++|GWA2|.|GWB2|++.++

Figure2:PeeringwithSBC

FromtheSBC'sperspectivetheOperatorAistheouternetwork,andOperatorBistheinnernetwork.OperatorBcanusetheSBC,forexample,tocontrolaccesstoitsnetwork,protectitsgatewaysandsoftswitchesfromunauthorizeduseanddenialofservice(DoS)attacks,andmonitorthesignalingandmediatraffic.ItalsosimplifiesnetworkmanagementbyminimizingthenumberofACL(AccessControlList)entriesinthegateways.Thegatewaysdonotneedtobeexposedtothepeernetwork,andtheycanrestrictaccess(bothmediaandsignaling)totheSBCs.TheSBChelpsensurethatonlymediafromsessionstheSBCauthorizeswillreachthegateway.

2.2.AccessScenario

Inanaccessscenario,presentedinFigure3,theSBCisplacedattheborderbetweentheaccessnetwork(outernetwork)andtheoperator'snetwork(innernetwork)tocontrolaccesstotheoperator'snetwork,protectitscomponents(mediaservers,




applicationservers,gateways,etc.)fromunauthorizeduseandDoSattacks,andmonitorthesignalingandmediatraffic.Also,sincetheSBCiscallstateful,itmayprovideaccesscontrolfunctionstopreventoversubscriptionoftheaccesslinks.EndpointsareconfiguredwiththeSBCastheiroutboundproxyaddress.TheSBCroutesrequeststooneormoreproxiesintheoperatornetwork.

AccessNetworkOperatorNetwork

++|UA1|++++|UA2||SBC||proxy|++++/++++/|UA3++NAT|




3.FunctionsofSBCs

ThissectionliststhosefunctionsthatareusedinSBCdeploymentsincurrentcommunicationnetworks.Eachsubsectiondescribesaparticularfunctionorfeature,theoperators'requirementsforhavingit,explanationofanyimpacttotheendtoendSIParchitecture,andaconcreteimplementationexample.Eachsectionalsodiscussespotentialconcernsspecifictothatparticularimplementationtechnique.SuggestionsforalternativeimplementationtechniquesthatmaybemorearchitecturallycompatiblewithSIPareoutsidethescopeofthisdocument.

Alltheexamplesgiveninthissectionaresimplified;onlytherelevantheaderlinesfromSIPandSDP(SessionDescriptionProtocol)[7]messagesaredisplayed.

3.1.TopologyHiding

3.1.1.GeneralInformationandRequirements

Topologyhidingconsistsoflimitingtheamountoftopologyinformationgiventoexternalparties.OperatorshavearequirementforthisfunctionalitybecausetheydonotwanttheIPaddressesoftheirequipment(proxies,gateways,applicationservers,etc.)tobeexposedtooutsideparties.ThismaybebecausetheydonotwanttoexposetheirequipmenttoDoSattacks,theymayuseothercarriersforcertaintrafficanddonotwanttheircustomerstobeawareofit,ortheymaywanttohidetheirinternalnetworkarchitecturefromcompetitorsorpartners.Insomeenvironments,theoperator'scustomersmaywishtohidetheaddressesoftheirequipmentortheSIPmessagesmaycontainprivate,nonroutableaddresses.

Themostcommonformoftopologyhidingistheapplicationofheaderprivacy(seeSection5.1of[2]),whichinvolvesstrippingViaandRecordRouteheaders,replacingtheContactheader,andevenchangingCallIDs.However,indeploymentsthatuseIPaddressesinsteadofdomainnamesinheadersthatcannotberemoved(e.g.,FromandToheaders),theSBCmayreplacetheseIPaddresseswithitsownIPaddressordomainname.

Forareference,therearealsootherwaysofhidingtopologyinformationthaninsertinganintermediary,likeanSBC,tothesignalingpath.OneofthewaysistheUAdrivenprivacymechanism[8],wheretheUAcanfacilitatetheconcealmentoftopologyinformation.




3.1.2.ArchitecturalIssues

Performingtopologyhiding,asdescribedabove,bySBCsthatdonothavetheusers'consentpresentssomeissues.Thisfunctionalityisbasedonahopbyhoptrustmodelasopposedtoanendtoendtrustmodel.Themessagesaremodifiedwithoutthesubscriber'sconsentandcouldpotentiallymodifyorremoveinformationabouttheuser'sprivacy,securityrequirements,andhigherlayerapplicationsthatarecommunicatedendtoendusingSIP.NeitheruseragentinanendtoendcallhasanywaytodistinguishtheSBCactionsfromamaninthemiddle(MITM)attack.

ThetopologyhidingfunctiondoesnotworkwellwithAuthenticatedIdentityManagement[4]inscenarioswheretheSBCdoesnothaveanykindofconsentfromtheusers.TheAuthenticatedIdentityManagementmechanismisbasedonahashvaluethatiscalculatedfrompartsofFrom,To,CallID,CSeq,Date,andContactheaderfieldsplusfromthewholemessagebody.IftheauthenticationserviceisnotprovidedbytheSBCitself,themodificationoftheaforementionedheaderfieldsandthemessagebodyisinviolationof[4].Someformsoftopologyhidingareinviolation,becausetheyare,e.g.,replacingtheContactheaderofaSIPmessage.

3.1.3.Example

ThecurrentwayofimplementingtopologyhidingconsistsofhavinganSBCactasaB2BUA(BacktoBackUserAgent)andremovealltracesoftopologyinformation(e.g.,ViaandRecordRouteentries)fromoutgoingmessages.

Imaginethefollowingexamplescenario:theSBC(p4.domain.example.com)receivesanINVITErequestfromtheinnernetwork,whichinthiscaseisanoperatornetwork.ThereceivedSIPmessageisshowninFigure4.




INVITEsip:[email protected]/2.0Via:SIP/2.0/UDPp3.middle.example.com;branch=z9hG4bK48jq9w174131.1Via:SIP/2.0/UDPp2.example.com;branch=z9hG4bK18an6i9234172.1Via:SIP/2.0/UDPp1.example.com;branch=z9hG4bK39bn2e5239289.1Via:SIP/2.0/UDPu1.example.com;branch=z9hG4bK92fj4u7283927.1Contact:sip:[email protected]:RecordRoute:RecordRoute:

Figure4:INVITERequestPriortoTopologyHiding

Then,theSBCperformsatopologyhidingfunction.Inthisscenario,theSBCremovesandstoresallexistingViaandRecordRouteheaders,andtheninsertsViaandRecordRouteheaderfieldswithitsownSIPURI.Afterthetopologyhidingfunction,themessagecouldappearasshowninFigure5.

INVITEsip:[email protected]/2.0Via:SIP/2.0/UDPp4.domain.example.com;branch=z9hG4bK92es3w230129.1Contact:sip:[email protected]:

Figure5:INVITERequestafterTopologyHiding

LikearegularproxyserverthatinsertsaRecordRouteentry,theSBChandleseverysinglemessageofagivenSIPdialog.IftheSBClosesstate(e.g.,SBCrestartsforsomereason),itmaynotbeabletoroutemessagesproperly(note:someSBCspreservethestateinformationalsoonrestart).Forexample,iftheSBCremovesViaentriesfromarequestandthenrestarts,thuslosingstate;theSBCmaynotbeabletorouteresponsestothatrequest,dependingontheinformationthatwaslostwhentheSBCrestarted.

Thisisonlyoneexampleoftopologyhiding.Besidestopologyhiding(i.e.,informationrelatedtothenetworkelementsisbeinghidden),SBCsmayalsodoidentityhiding(i.e.,informationrelatedtoidentityofsubscribersisbeinghidden).Whileperformingidentityhiding,SBCsmaymodifyContactheaderfieldvaluesandotherheaderfieldscontainingidentityinformation.TheheaderfieldscontainingidentityinformationislistedinSection4.1of[2].Sincethepublicationof[2],thefollowingheaderfieldscontainingidentityinformationhavebeendefined:"PAssertedIdentity","ReferredBy","Identity",and"IdentityInfo".




3.2.MediaTrafficManagement


Mediatrafficmanagementisthefunctionofcontrollingmediatraffic.Networkoperatorsmayrequirethisfunctionalityinordertocontrolthetrafficbeingcarriedontheirnetworkonbehalfoftheirsubscribers.Trafficmanagementhelpsthecreationofdifferentkindsofbillingmodels(e.g.,videotelephonycanbepriceddifferentlythanvoiceonlycalls)anditalsomakesitpossibleforoperatorstoenforcetheusageofselectedcodecs.

Oneoftheusecasesformediatrafficmanagementistheimplementationofinterceptcapabilitiesthatarerequiredtosupportauditorlegalobligations.Itisnoteworthythatthelegalobligationsmainlyapplytooperatorsprovidingvoiceservices,andthoseoperatorstypicallyhaveinfrastructure(e.g.,SIPproxiesactingasB2BUAs)forprovidinginterceptcapabilitiesevenwithoutSBCs.

Sincethemediapathisindependentofthesignalingpath,themediamaynottraversethroughtheoperator'snetworkunlesstheSBCmodifiesthesessiondescription.Bymodifyingthesessiondescription,theSBCcanforcethemediatobesentthroughamediarelaywhichmaybecolocatedwiththeSBC.Thiskindoftrafficmanagementcanbedone,forexample,toensureacertainQoSlevel,ortoensurethatsubscribersareusingonlyallowedcodecs.ItisnoteworthythattheSBCsdonothavedirecttiestoroutingtopologyandtheydonot,forexample,changebandwidthreservationsonTrafficEngineering(TE)tunnels,nordotheyhavedirectinteractionwithroutingprotocol.

Someoperatorsdonotwanttomanagethetraffic,butonlytomonitorittocollectstatisticsandmakesurethattheyareabletomeetanybusinessservicelevelagreementswiththeirsubscribersand/orpartners.Theprotocoltechniques,fromtheSBC'sviewpoint,neededformonitoringmediatrafficarethesameasformanagingmediatraffic.

SBCsonthemediapatharealsocapableofdealingwiththe"lostBYE"issueifeitherendpointdiesinthemiddleofthesession.TheSBCcandetectthatthemediahasstoppedflowingandissueaBYEtobothsidestocleanupanystateinotherintermediateelementsandtheendpoints.

OnepossibleformofmediatrafficmanagementisthatSBCsterminatemediastreamsandSIPdialogsbygeneratingBYErequests.Thiskindofprocedurecantakeplace,forexample,inasituationwherethe




subscriberrunsoutofcredits.MediamanagementisneededtoensurethatthesubscribercannotjustignoretheBYErequestgeneratedbytheSBCandcontinueitsmediasessions.


ImplementingtrafficmanagementinthismannerrequirestheSBCtoaccessandmodifythesessiondescriptions(i.e.,offersandanswers)exchangedbetweentheuseragents.Consequently,thisapproachdoesnotworkifuseragentsencryptorintegrityprotecttheirmessagebodiesendtoend.Again,messagesaremodifiedwithoutsubscriberconsent,anduseragentsdonothaveanywaytodistinguishtheSBCactionsfromanattackbyaMITM.Furthermore,thisisinviolationofAuthenticatedIdentityManagement[4],seeSection3.1.2.

Theinsertionofamediarelaycanprevent"nonmedia"usesofthemediapath,forexample,themediapathkeyagreement.Sometimesthistypeofpreventionisintentional,butitisnotalwaysnecessary.Forexample,ifanSBCisusedjustforenablingmediamonitoring,butnotforinterception.

Therearesomepossibleissuesrelatedtothemediarelaying.Ifthemediarelayingisnotdoneinthecorrectmanner,itmaybreakfunctionslikeExplicitCongestionNotification(ECN)andPathMTUDiscovery(PMTUD),forexample.ThemediarelayseasilybreaksuchIPandtransportlayerfunctionalitiesthatrelyonthecorrecthandlingoftheprotocolfields.Someespeciallysensitivefieldsare,forexample,ECNandTypeofService(ToS)fieldsandtheDon'tFragment(DF)bit.

Thewayinwhichmediatrafficmanagementfunctionsimpedesinnovation.Thereasonfortheimpedimentisthatinmanycases,SBCsneedtobeabletosupportnewformsofcommunication(e.g.,extensionstotheSDPprotocol)beforenewservicescanbeputintouse,whichslowstheadoptionofnewinnovations.

IfanSBCdirectsmanymediastreamsthroughacentralpointinthenetwork,itislikelytocauseasignificantamountofadditionaltraffictoapathtothatcentralpoint.Thismightcreatepossiblebottleneckinthepath.

Inthisapplication,theSBCmayoriginatemessagesthattheusermaynotbeabletoauthenticateascomingfromthedialogpeerortheSIPRegistrar/Proxy.




3.2.3.Example

Trafficmanagementmaybeperformedinthefollowingway:TheSBCbehavesasaB2BUAandinsertsitself,orsomeotherentityundertheoperator'scontrol,inthemediapath.Inpractice,theSBCmodifiesthesessiondescriptionscarriedintheSIPmessages.Asaresult,theSBCreceivesmediafromoneuseragentandrelaysittotheotheruseragentandperformstheidenticaloperationwithmediatravelinginthereversedirection.

AsmentionedinSection3.2.1,codecrestrictionisaformoftrafficmanagement.TheSBCrestrictsthecodecsetnegotiatedintheoffer/answerexchange[5]betweentheuseragents.Aftermodifyingthesessiondescriptions,theSBCcancheckwhetherornotthemediastreamcorrespondstowhatwasnegotiatedintheoffer/answerexchange.Ifitdiffers,theSBChastheabilitytoterminatethemediastreamortakeotherappropriate(configured)actions(e.g.,raiseanalarm).

Considerthefollowingexamplescenario:theSBCreceivesanINVITErequestfromtheouternetwork,whichinthiscaseisanaccessnetwork.ThereceivedSIPmessagecontainstheSDPsessiondescriptorshowninFigure6.

v=0o=owner28908445262890842807INIP4192.0.2.4c=INIP4192.0.2.4m=audio49230RTP/AVP9698a=rtpmap:96L8/8000a=rtpmap:98L16/16000/2

Figure6:RequestPriortoMediaManagement

Inthisexample,theSBCperformsthemediatrafficmanagementfunctionbyrewritingthe"m="line,andremovingone"a="lineaccordingtosome(external)policy.Figure7showsthesessiondescriptionafterthetrafficmanagementfunction.

v=0o=owner28908445262890842807INIP4192.0.2.4c=INIP4192.0.2.4m=audio49230RTP/AVP96a=rtpmap:96L8/8000

Figure7:RequestBodyAfterMediaManagement




MediatrafficmanagementhasaproblemwheretheSBCneedstounderstandthesessiondescriptionprotocolandallextensionsusedbytheuseragents.Thismeansthatinordertouseanewextension(e.g.,anextensiontoimplementanewservice)oranewsessiondescriptionprotocol,SBCsinthenetworkmayneedtobeupgradedinconjunctionwiththeendpoints.Itisnoteworthythatasimilarproblem,butwithheaderfields,appliesto,forexample,topologyhidingfunction,seeSection3.1.CertainextensionsthatdonotrequireactivemanipulationofthesessiondescriptorstofacilitatetrafficmanagementwillbeabletobedeployedwithoutupgradingexistingSBCs,dependingonthedegreeoftransparencytheSBCimplementationaffords.IncasesrequiringanSBCmodificationtosupportthenewprotocolfeatures,therateofservicedeploymentmaybeaffected.

3.3.FixingCapabilityMismatches


SBCsfixingcapabilitymismatchesenablecommunicationsbetweenuseragentswithdifferentcapabilitiesorextensions.Forexample,anSBCcanenableaplainSIP[1]useragenttoconnecttoa3GPPnetwork,orenableaconnectionbetweenuseragentsthatsupportdifferentIPversions,differentcodecs,orthatareindifferentaddressrealms.Operatorshavearequirementandastrongmotivationforperformingcapabilitymismatchfixing,sothattheycanprovidetransparentcommunicationacrossdifferentdomains.Insomecases,differentSIPextensionsormethodstoimplementthesameSIPapplication(likemonitoringsessionliveness,callhistory/diversionetc.)mayalsobeinterworkedthroughtheSBC.


SBCsthatarefixingcapabilitymismatchesdoitbyinsertingamediaelementintothemediapathusingtheproceduresdescribedinSection3.2.Therefore,theseSBCshavethesameconcernsasSBCsperformingtrafficmanagement:theSBCmaymodifySIPmessageswithoutconsentfromanyoftheuseragents.Thismaybreakendtoendsecurityandapplicationextensionsnegotiation.

Thecapabilitymismatchfixingisafragilefunctioninthelongterm.Thenumberofincompatibilitiesbuiltintovariousnetworkelementsisincreasingthefragilityandcomplexityovertime.ThismightleadtoasituationwhereSBCsneedtobeabletohandlealargenumberofcapabilitymismatchesinparallel.




3.3.3.Example

ConsiderthefollowingexamplescenariowheretheinnernetworkisanaccessnetworkusingIPv4andtheouternetworkisusingIPv6.TheSBCreceivesanINVITErequestwithasessiondescriptionfromtheaccessnetwork:

INVITEsip:[email protected]/2.0Via:SIP/2.0/UDP192.0.2.4Contact:sip:[email protected]

v=0o=owner28908445262890842807INIP4192.0.2.4c=INIP4192.0.2.4m=audio49230RTP/AVP96a=rtpmap:96L8/8000

Figure8:RequestPriortoCapabilitiesMatch

Then,theSBCperformsacapabilitymismatchfixingfunction.Inthisscenario,theSBCinsertsRecordRouteandViaheadersandrewritesthe"c="linefromthesessionsdescriptor.Figure9showstherequestafterthecapabilitymismatchadjustment.

INVITEsip:[email protected]/2.0RecordRoute:Via:SIP/2.0/UDPsip:[2001:DB8::801:201:2ff:fe94:8e10]Via:SIP/2.0/UDP192.0.2.4Contact:sip:[email protected]

v=0o=owner28908445262890842807INIP4192.0.2.4c=INIP62001:DB8::801:201:2ff:fe94:8e10m=audio49230RTP/AVP96a=rtpmap:96L8/8000

Figure9:RequestafterCapabilityMatch

ThismessageisthensentbytheSBCtotheonwardIPv6network.

3.4.MaintainingSIPRelatedNATBindings


NATtraversalinthisinstancereferstothespecificmessagemodificationsrequiredtoassistauseragentinmaintainingSIPandmediaconnectivitywhenthereisaNATdevicelocatedbetweenauseragentandaproxy/registrarand,possibly,anyotheruseragent.The




primarypurposeofNATtraversalfunctionistokeepupacontrolconnectiontouseragentsbehindNATs.Thiscan,forexample,beachievedbygeneratingperiodicnetworktrafficthatkeepsbindingsinNATsalive.SBCs'NATtraversalfunctionisrequiredinscenarioswheretheNATisoutsidetheSBC(i.e.,notincaseswhereSBCitselfactsasaNAT).

AnSBCperformingaNAT(NetworkAddressTranslator)traversalfunctionforauseragentbehindaNATsitsbetweentheuseragentandtheregistrarofthedomain.NATsarewidelydeployedinvariousaccessnetworkstoday,sooperatorshavearequirementtosupportit.WhentheregistrarreceivesaREGISTERrequestfromtheuseragentandrespondswitha200(OK)response,theSBCmodifiessucharesponsedecreasingthevalidityoftheregistration(i.e.,theregistrationexpiressooner).ThisforcestheuseragenttosendanewREGISTERtorefreshtheregistrationsoonerthatitwouldhavedoneonreceivingtheoriginalresponsefromtheregistrar.TheREGISTERrequestssentbytheuseragentrefreshthebindingoftheNATbeforethebindingexpires.

NotethattheSBCdoesnotneedtorelayalltheREGISTERrequestsreceivedfromtheuseragenttotheregistrar.TheSBCcangenerateresponsestoREGISTERrequestsreceivedbeforetheregistrationisabouttoexpireattheregistrar.Moreover,theSBCneedstoderegistertheuseragentifthisfailstorefreshitsregistrationintime,eveniftheregistrationattheregistrarwouldstillbevalid.

SBCscanalsoforcetraffictogothroughamediarelayforNATtraversalpurposes(moreaboutmediatrafficmanagementinSection3.2).Atypicalcallhasmediastreamstotwodirections.EventhoughSBCscanforcemediastreamsfrombothdirectionstogothroughamediarelay,insomecases,itisenoughtorelayonlythemediafromonedirection(e.g.,inascenariowhereonlytheotherendpointisbehindaNAT).


ThisapproachtoNATtraversaldoesnotworkifendtoendconfidentialityorintegrityprotectionmechanismsareused(e.g.,Secure/MultipurposeInternetMailExtensions(S/MIME)).TheSBCwouldbeseenasaMITMmodifyingthemessagesbetweentheuseragentandtheregistrar.

ThereisalsoaproblemrelatedtothemethodofhowSBCschoosethevalueforthevalidityofaregistrationperiod.Thisvalueshouldbeashighaspossible,butitstillneedstobelowenoughtomaintaintheNATbinding.SomeSBCsdonothaveanydeterministic




methodforchoosingasuitablevalue.However,SBCscanjustuseasuboptimal,relativelysmallvaluethatusuallyworks.Anexamplefromsuchvalueis15seconds(see[9]).

NATtraversalformediausingSBCsposesfewissuesaswell.Forexample,anSBCnormallyguessestherecipient'spublicIPaddressononeofthemediastreamsrelayedbytheSBCbysnoopingonthesourceIPaddressofanothermediastreamrelayedbythesameSBC.ThiscausessecurityandinteroperabilityissuessincetheSBCcanendupassociatingwrongdestinationIPaddressesonmediastreamsitisrelaying.Forexample,anattackermaysnooponthelocalIPaddressandportsusedbytheSBCformediarelayingthestreamsandsendafewpacketsfromamaliciousIPaddresstothesedestinations.Inmostcases,thiscancausemediastreamsintheoppositedirectionstodiverttraffictotheattackerresultinginasuccessfulMITMorDoSattack.AsimilarexampleofaninteroperabilityissueiscausedwhenanendpointbehindaNATattemptstoswitchtheIPaddressofthemediastreamsbyusingareINVITE.Ifanymediapacketsarereorderedordelayedinthenetwork,theycancausetheSBCtoblocktheswitchfromhappeningevenifthereINVITEsuccessfullygoesthrough.

3.4.3.Example

Considerthefollowingexamplescenario:TheSBCresidesbetweentheUAandRegistrar.Previously,theUAhassentaREGISTERrequesttotheRegistrar,andtheSBCreceivestheregistrationresponseshowninFigure10.

SIP/2.0200OKFrom:Bob;tag=a73kszlflTo:Bob;tag=34095828jhCSeq:1REGISTERContact:;expires=3600

Figure10:ResponsePriortoNATMaintenanceFunction

WhenperformingtheNATtraversalfunction,theSBCmayrewritetheexpirytimetocoaxtheUAtoreregisterpriortotheintermediatingNATdecidingtoclosethepinhole.Figure11showsapossiblemodificationoftheresponsefromFigure10.




SIP/2.0200OKFrom:Bob;tag=a73kszlflTo:Bob;tag=34095828jhCSeq:1REGISTERContact:;expires=60

Figure11:ManipulatedResponseforNATTraversal

Naturally,othermeasurescouldbetakeninordertoenabletheNATtraversal(e.g.,nonSIPkeepalivemessages),butthisexampleillustratesonlyonemechanismforpreservingtheSIPrelatedNATbindings.

3.5.AccessControl


Networkoperatorsmaywishtocontrolwhatkindofsignalingandmediatraffictheirnetworkcarries.Thereisstrongmotivationandarequirementtodoaccesscontrolontheedgeofanoperator'snetwork.Accesscontrolcanbebasedon,forexample,linklayeridentifiers,IPaddressesorSIPidentities.

ThisfunctioncanbeimplementedbyprotectingtheinnernetworkwithfirewallsandconfiguringthemsothattheyonlyacceptSIPtrafficfromtheSBC.Thisway,alltheSIPtrafficenteringtheinnernetworkneedstoberoutedthoughtheSBC,whichonlyroutesmessagesfromauthorizedpartiesortrafficthatmeetsaspecificpolicythatisexpressedintheSBCadministratively.

Accesscontrolcanbeappliedtoeitheronlythesignalingorboththesignalingandmedia.Ifitisappliedonlytothesignaling,thentheSBCmightbehaveasaproxyserver.Ifaccesscontrolisappliedtoboththesignalingandmedia,thentheSBCbehavesinasimilarmannerasexplainedinSection3.2.AkeypartofmedialayeraccesscontrolisthatonlymediaforauthorizedsessionsisallowedtopassthroughtheSBCand/orassociatedmediarelaydevices.

Operatorsimplementsomefunctionalities,likeNATtraversalforexample,inanSBCinsteadofotherelementsintheinnernetworkforseveralreasons:(i)preventingpacketsfromunregistereduserstopreventchancesofDoSattack,(ii)prioritizationand/orreroutingoftraffic(basedonuserorservice,likeE911)asitentersthenetwork,and(iii)performingaloadbalancingfunctionorreducingtheloadonothernetworkequipment.




Inenvironmentswherethereislimitedbandwidthontheaccesslinks,theSBCcancomputethepotentialbandwidthusebyexaminingthecodecspresentinSDPoffersandanswers.Withthisinformation,theSBCcanrejectsessionsbeforetheavailablebandwidthisexhaustedtoallowexistingsessionstomaintainacceptablequalityofservice.Otherwise,thelinkcouldbecomeoversubscribedandallsessionswouldexperienceadeteriorationinqualityofservice.SBCsmaycontactapolicyservertodeterminewhethersufficientbandwidthisavailableonapersessionbasis.


SincetheSBCneedstohandleallSIPmessages,thisfunctionhasscalabilityimplications.Inaddition,theSBCisasinglepointoffailurefromanarchitecturalpointofview.Although,inpractice,manycurrentSBCshavethecapabilitytosupportredundantconfiguration,whichpreventsthelossofcallsand/orsessionsintheeventofafailureonasinglenode.

Ifaccesscontrolisperformedonlyonbehalfofsignaling,thentheSBCiscompatiblewithgeneralSIParchitecturalprinciples,butifitisperformedforsignalingandformedia,thentherearesimilarproblemsasdescribedinSection3.2.2.

3.5.3.Example

Figure12showsacallflowwheretheSBCisprovidingbothsignalingandmediaaccesscontrol(ACKsomittedforbrevity).




callerSBCcallee||||Identifythecaller|||||||||INVITE+SDP|||>|||[ModifytheSDP]|||INVITE+modifiedSDP|||>||||||200OK+SDP|||





Inmanycases,doingprotocolrepairforSIPheaderfieldscanbeseenasbeingcompatiblewithSIParchitecturalprinciples,anditdoesnotviolatetheendtoendmodelofSIP.TheSBCrepairingprotocolmessagesbehavesasaproxyserverthatisliberalinwhatitacceptsandstrictinwhatitsends.

However,protocolrepairmaybreaksecuritymechanismthatdocryptographicalcomputationsonSIPheadervalues.AttemptingprotocolrepairforSIPmessagebodies(SDP)isincompatiblewithAuthenticatedIdentityManagement[4]andendtoendsecuritymechanismssuchasS/MIME.

Asimilarproblemrelatedtoincreasingcomplexity,asexplainedinSection3.3.2,alsoaffectsprotocolrepairfunction.

3.6.3.Examples

TheSBCcan,forexample,receiveanINVITEmessagefromarelativelynewSIPUAasillustratedinFigure13.

INVITEsip:[email protected]:SIP/2.0/UDPu1.example.com:5060;lrFrom:CallerTo:CalleeCallID:[email protected]:1INVITEContact:sip:[email protected]

Figure13:RequestfromaRelativelyNewClient

IftheSBCdoesprotocolrepair,itcanrewritethe'lr'parameterontheViaheaderfieldintotheform'lr=true'inordertosupportsomeolder,badlyimplementedSIPstacks.ItcouldalsoremoveexcesswhitespacestomaketheSIPmessagemorehumanreadable.

3.7.MediaEncryption


SBCsareusedtoperformmediaencryption/decryptionattheedgeofthenetwork.Thisisthecasewhenmediaencryption(e.g.,SecureRealtimeTransportProtocol(SRTP))isusedonlyontheaccessnetwork(outernetwork)sideandthemediaiscarriedunencryptedintheinnernetwork.Someoperatorsprovidetheabilitytodolegal




interceptionwhilestillgivingtheircustomerstheabilitytoencryptmediaintheaccessnetwork.Onepossiblewaytodothisistoperformmediaencryptionfunction.


Whileperformingamediaencryptionfunction,SBCsneedtobeabletoinjecteitherthemselves,orsomeotherentitytothemediapath.ItmustbenotedthatthiskindofbehavioristhesameasaclassicalMITMattack.Duetothis,theSBCshavethesamearchitecturalissuesasexplainedinSection3.2.

3.7.3.Example

Figure14showsanexamplewheretheSBCisperformingmediaencryptionrelatedfunctions(ACKsomittedforbrevity).

callerSBC#1SBC#2callee|||||INVITE+SDP||||>||||[ModifytheSDP]||||||||INVITE+mod.SDP||||>||||[ModifytheSDP]||||||||INVITE+mod.SDP||||>||||||||200OK+SDP||||




First,theUACsendsanINVITErequest,andthefirstSBCmodifiesthesessiondescriptorinawaythatitinjectsitselftothemediapath.ThesamehappensinthesecondSBC.Then,theUserAgentServer(UAS)replieswitha200OKresponseandtheSBCsinjectthemselvesinthereturningmediapath.Aftersignaling,themediastartsflowing,andbothSBCsperformmediaencryptionanddecryption.

4.DerivedRequirementsforFutureSIPStandardizationWork

SomeofthefunctionslistedinthisdocumentaremoreSIPunfriendlythanothers.ThislistofrequirementsisderivedfromthefunctionsthatbreaktheprinciplesofSIPinonewayoranotherwhenperformedbySBCsthatdonothavetheusers'consent.Thederivedrequirementsare:

Req1:ThereshouldbeaSIPfriendlywaytohidenetworktopologyinformation.Currently,thisisdonebystrippingandreplacingheaderfields,whichisagainsttheprinciplesofSIPonbehalfofsomeheaderfields(seeSection3.1).

Req2:ThereshouldbeaSIPfriendlywaytodirectmediatrafficthroughintermediaries.Currently,thisisdonebymodifyingsessiondescriptors,whichisagainsttheprinciplesofSIP(seeSections3.2,3.4,3.5,and3.7).

Req3:ThereshouldbeaSIPfriendlywaytofixcapabilitymismatchesinSIPmessages.Thisrequirementishardertofulfilloncomplexmismatchcases,likethe3GPP/SIP[1]networkmismatch.Currently,thisisdonebymodifyingSIPmessages,whichmayviolateendtoendsecurity(seeSections3.3and3.6),onbehalfofsomeheaderfields.

Req1andReq3donothaveanexisting,standardizedsolutiontoday.ThereisongoingworkintheIETFforaddressingReq2,suchasSIPsessionpolicies[10],TraversalUsingRelaysaroundNAT(TURN)[11],andInteractiveConnectivityEstablishment(ICE)[12].Nonetheless,futureworkisneededinordertodevelopsolutionstotheserequirements.

5.SecurityConsiderations

Manyofthefunctionsthisdocumentdescribeshaveimportantsecurityandprivacyimplications.OnemajorsecurityproblemisthatmanyfunctionsimplementedbySBCs(e.g.,topologyhidingandmediatrafficmanagement)modifySIPmessagesandtheirbodieswithouttheuseragents'consent.Theresultisthattheuseragentsmay




interprettheactionstakenbyanSBCasaMITMattack.SBCsmodifySIPmessagesbecauseitallowsthemto,forexample,protectelementsintheinnernetworkfromdirectattacks.

SBCsthatplacethemselves(oranotherentity)onthemediapathcanbeusedtoeavesdroponconversations.Since,often,useragentscannotdistinguishbetweentheactionsofanattackerandthoseofanSBC,userscannotknowwhethertheyarebeingeavesdroppedonorifanSBConthepathisperformingsomeotherfunction.SBCsplacethemselvesonthemediapathbecauseitallowsthemto,forexample,performlegalinterception.

Onagenerallevel,SBCspreventtheuseofendtoendauthentication.ThisisbecauseSBCsneedtobeabletoperformactionsthatlooklikeMITMattacks,andinorderforuseragentstocommunicate,theymustallowthosetypeofattacks.Itotherwords,useragentscannotuseendtoendsecurity.Thisisespeciallyharmfulbecauseothernetworkelements,besidesSBCs,arethenabletodosimilarattacks.However,insomecases,useragentscanestablishencryptedmediaconnectionsbetweenoneanother.OneexampleisascenariowhereSBCisusedforenablingmediamonitoringbutnotforinterception.

AnSBCisasinglepointoffailurefromthearchitecturalpointofview.ThismakesitanattractivetargetforDoSattacks.ThefactthatsomefunctionsofSBCsrequirethoseSBCstomaintainsessionspecificinformationmakesthesituationevenworse.IftheSBCcrashes(orisbroughtdownbyanattacker),ongoingsessionsexperienceundeterminedbehavior.

IftheIETFdecidestodevelopstandardmechanismstoaddresstherequirementspresentedinSection4,thesecurityandprivacyrelatedaspectsofthosemechanismswill,ofcourse,needtobetakenintoconsideration.

6.Acknowledgements

TheadhocmeetingaboutSBCs,heldonNovember9,2004inWashingtonDCduringthe61stIETFmeeting,providedvaluableinputtothisdocument.TheauthorswouldalsoliketothankSridharRamachandran,GauravKulshreshtha,andRakenduDevdhar.ReviewersSpencerDawkinsandFrancoisAudetalsodeservespecialthanks.




7.References

7.1.NormativeReferences

[1]Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,Handley,M.,andE.Schooler,"SIP:SessionInitiationProtocol",RFC3261,June2002.

[2]Peterson,J.,"APrivacyMechanismfortheSessionInitiationProtocol(SIP)",RFC3323,November2002.

[3]Willis,D.andB.Hoeneisen,"SessionInitiationProtocol(SIP)ExtensionHeaderFieldforRegisteringNonAdjacentContacts",RFC3327,December2002.

[4]Peterson,J.andC.Jennings,"EnhancementsforAuthenticatedIdentityManagementintheSessionInitiationProtocol(SIP)",RFC4474,August2006.

[5]Rosenberg,J.andH.Schulzrinne,"AnOffer/AnswerModelwithSessionDescriptionProtocol(SDP)",RFC3264,June2002.

7.2.InformativeReferences

[6]3GPP,"IPMultimediaSubsystem(IMS);Stage2",3GPPTS23.22810.0.0,March2010.

[7]Handley,M.,Jacobson,V.,andC.Perkins,"SDP:SessionDescriptionProtocol",RFC4566,July2006.

[8]Munakata,M.,Schubert,S.,andT.Ohba,"UserAgentDrivenPrivacyMechanismforSIP",RFC5767,April2010.

[9]Eggert,L.andG.Fairhurst,"UnicastUDPUsageGuidelinesforApplicationDesigners",BCP145,RFC5405,November2008.

[10]Hilt,V.,Camarillo,G.,andJ.Rosenberg,"AFrameworkforSessionInitiationProtocol(SIP)SessionPolicies",WorkinProgress,February2010.

[11]Mahy,R.,Matthews,P.,andJ.Rosenberg,"TraversalUsingRelaysaroundNAT(TURN):RelayExtensionstoSessionTraversalUtilitiesforNAT(STUN)",RFC5766,April2010.

[12]Rosenberg,J.,"InteractiveConnectivityEstablishment(ICE):AProtocolforNetworkAddressTranslator(NAT)TraversalforOffer/AnswerProtocols",RFC5245,MonthTBD2010.




Authors'Addresses

JaniHautakorpi(editor)EricssonHirsalantie11Jorvas02420Finland

EMail:[email protected]

GonzaloCamarilloEricssonHirsalantie11Jorvas02420Finland


RobertF.PenfieldAcmePacket71ThirdAvenueBurlington,MA01803US


AlanHawrylyshenSkype,Inc.2055E.HamiltonAveSanJose,CA95125US


MedhaviBhatia3CLogic9700GreatSenecaHwy.Rockville,MD20850US


Date post:	27-Sep-2015
Category:	Documents
Upload:	saraya82
View:	30 times
Download:	3 times