Network Intrusion Detection: Evasion,Traffic Normalization, and End-to-End ProtocolSemantics

Mark Handley andVernPaxsonAT&T Centerfor InternetResearch at ICSI (ACIRI)

InternationalComputerScienceInstituteBerkeley, CA94704 USA�

mjh,vern� @aciri.org

ChristianKreibichInstitut fur Informatik

TechnischeUniversitat Munchen80290Munchen,Germany

kreibich@cs.tum.edu

Abstract

A fundamentalproblemfor network intrusiondetectionsys-temsis the ability of a skilled attacker to evadedetectionbyexploiting ambiguitiesin thetraffic streamasseenby themon-itor. We discussthe viability of addressingthis problembyintroducinga new network forwardingelementcalleda trafficnormalizer. The normalizersits directly in the path of traf-fic into a site andpatchesup the packet streamto eliminatepotentialambiguitiesbeforethe traffic is seenby the moni-tor, removing evasionopportunities. We examinea numberof tradeoffs in designinganormalizer, emphasizingtheimpor-tantquestionof thedegreeto whichnormalizationsundermineend-to-endprotocolsemantics.We discussthe key practicalissuesof “cold start” andattackson the normalizer, andde-velop a methodologyfor systematicallyexaminingthe ambi-guitiespresentin a protocolbasedon walking the protocol’sheader. We thenpresentnorm, a publicly availableuser-levelimplementationof anormalizerthatcannormalizeaTCPtraf-fic streamat 100,000pkts/secin memory-to-memorycopies,suggestingthat a kernel implementationusing PC hardwarecouldkeeppacewith a bidirectional100Mbps link with suf-ficient headroomto weathera high-speedflooding attackofsmallpackets.

1 Intr oduction

A fundamentalproblemfor network intrusiondetectionsystems(NIDSs) that passively monitor a network linkis theability of a skilled attacker to evadedetectionbyexploitingambiguitiesin thetraffic streamasseenby theNIDS [14]. Exploitableambiguitiescanarisein three

differentways:

(i) TheNIDS maylackcompleteanalysisfor thefullrangeof behavior allowed by a particularproto-col. For example,an attacker canevadea NIDSthat fails to reassembleIP fragmentsby inten-tionally transmittingtheir attack traffic in frag-mentsratherthancompleteIP datagrams.SinceIP end-systemsarerequiredto performfragmentreassembly, theattacktraffic will still have thein-tendedeffectat thevictim, but theNIDS will missthe attackbecauseit never reconstructsthe com-pletedatagrams.

Of the four commercialsystemstestedby Ptacekand Newshamin 1998, nonecorrectly reassem-bledfragments[14].

Also note that an attacker can evade the NIDSeven if the NIDS doesperform analysisfor theprotocol(e.g.,it doesreassemblefragments)if theNIDS’s analysisis incomplete(e.g., it doesnotcorrectlyreassembleout-of-orderfragments).

(ii) Without detailedknowledge of the victim end-system’sprotocolimplementation,theNIDS maybe unableto determinehow the victim will treata given sequenceof packets if different imple-mentationsinterpret the samestreamof packetsin differentways. Unfortunately, Internetproto-col specificationsdonotalwaysaccuratelyspecifythecompletebehavior of protocols,especiallyforrareor exceptionalconditions.In addition,differ-entoperatingsystemsandapplicationsimplementdifferentsubsetsof theprotocols.

For example,whenan end-systemreceivesover-lapping IP fragments that differ in the pur-porteddatafor theoverlappingregion,someend-system’s may favor thedatafirst received,otherstheportionof theoverlappingfragmentpresentinthelowerfragment,otherstheportionin theupperfragment.

(iii) Withoutdetailedknowledgeof thenetwork topol-ogybetweentheNIDS andthevictim end-system,the NIDS may be unableto determinewhetheragivenpacketwill evenbeseenby theend-system.For example,a packet seenby theNIDS thathasa low Time To Live (TTL) field may or may nothavesufficienthopcountremainingto make it alltheway to theend-system[12]; seebelow for anexample.

If theNIDS believesa packet wasreceivedwhenin fact it did not reachthe end-system,then itsmodelof the end-system’s protocolstatewill beincorrect.If theattacker canfind waysto system-atically ensurethatsomepacketswill bereceivedandsomenot, the attacker may be ableto evadetheNIDS.

The first of theseshortcomingscan in principle be ad-dressedby a sufficiently diligent NIDS implementa-tion, making surethat its analysisof eachprotocol iscomplete. However, the other two shortcomingsaremore fundamental: in the absenceof external knowl-edge(end-systemimplementationdetails,topologyde-tails), no amountof analyzercompletenesswithin theNIDS canhelp it correctlydeterminethe end-system’sultimateprocessingof the packet stream.On the otherhand,the attacker maybe ableto determinetheseend-systemcharacteristicsfor a particularvictim by activelyprobingthevictim, perhapsin quitesubtle(veryhardtodetect)ways. Thus,anattacker cancraft their traffic sothat,whateveralgorithmstheNIDS analyzeruses,it willerr in determininghow theend-systembehaves.

Figure1 showsanexampleof anevasionattackthatcanexploit eitherof the last two shortcomingsabove. Theattacker fakesa missingpacket, thensendsa sequenceof TCP packetsabove the sequencehole that containsthe attack,and also sendsa sequenceof TCP packetscontaininginnocuousdatafor the sameTCP sequencespace.

For the moment, ignore the “timed out” packets andassumeall of the packetson the left arrive at the vic-tim. Even in this case,the NIDS needsto know pre-ciselyhow theend-systemwill interprettheinconsistent“retransmissions”—whetherit will use“n” or “r” for

t tTTL=21,seq=4�

o oTTL=21,seq=2�

lost�

n

c

r

o

Sender�

IDS

Receiver

r

otimed out

timed out seq=1

seq=2

seq=4

n or r?i or o?c or o?e ot t?

TTL=17, seq=1�TTL=23, seq=1�

i timed outTTL=15,seq=2�

TTL=19,seq=3�TTL=20,seq=3�

e timed outTTL=17,seq=4�

seq=3

Figure1: InconsistentTCP“retransmissions”

sequence#1, “o” or “i” for sequence#2, etc.—whenconstructingthe byte streampresentedto the applica-tion. Unfortunately, different TCP stacksdo differentthings in this error case;someacceptthe first packet,and somethe second. Thereis no simple-and-correctrule theNIDS canusefor its analysis.

In addition, the attacker may also be able to controlwhich of the packetsseenby the NIDS actuallyarriveat the end-systemandwhich do not. In Figure 1, theattacker doesso by manipulatingthe TTL field so thatsomeof the packets lack sufficient hop count to travelall the way to the victim. In this case,to disambiguatethe traffic theNIDS mustknow exactly how many for-wardinghopslie betweenit andthevictim.

Onemightarguethatsuchevasive traffic or activeprob-ing will itself appearanomalousto theNIDS, andthere-fore the NIDS candetectthat an attacker is attemptingto evadeit. However, doing so is greatlycomplicatedby two factors. First, detectionof an attemptat eva-siondegradestheprecisionof a NIDS’s detectiondownfrom identifying thespecificsof anattackto only beingableto flag thatanattackmightpossiblybein progress.Second,network traffic unfortunatelyoften includesanon-negligibleproportionof highly unusual,but benign,traffic, that will often result in falsepositivesconcern-ing possibleevasionattempts.This is discussedin [12]astheproblemof “crud”; examplesincludeinconsistentTCPretransmissionsandoverlappinginconsistentfrag-ments.

In theabove argumentwe assumetheattacker is awareof the existenceof the NIDS, hasaccessto its sourcecode(or candeducetheoperationof its algorithms)andattackprofile database,andthat the attacker is actively

trying to evadethe NIDS. All of theseare prudentorplausibleassumptions;for example,alreadythecrackercommunityhasdiscussedthe issues[5] andsomeeva-siontoolkits (developedby “white hats”to aid in testingandhardeningNIDSs)have beendeveloped[2]. Thus,we againemphasizethe seriousanddifficult natureofthis problem:unlessstepsaretakento addressall threeof the evasion issuesdiscussedabove, network intru-siondetectionbasedonpassivemonitoringof traffic willeventually be completelycircumventable,and provideno realprotectionto sitesrelyingon it.

In this paperwe considerthe viability of addressingtheevasion-by-ambiguityproblemby introducinganewnetwork forwardingelementcalleda traffic normalizer.Thenormalizer’sjob is to sit directlyin thepathof trafficinto a site (a “bump in the wire”) andpatchup or nor-malizethe packet streamto remove potentialambigui-ties.Theresultis thataNIDSmonitoringthenormalizedtraffic streamno longerneedsto considerpotentialam-biguitiesin interpretingthestream:thetraffic asseenbytheNIDS is guaranteedunambiguous,thanksto thenor-malizer. For example,anormalizerprocessingthetrafficshown in Figure1 might replacethedatain any subse-quentinconsistentretransmissionswith thedatafromtheoriginalversionof thesamesequencespace,sotheonlytext theNIDS (andtheend-system) wouldseewould benoct.

Internet Intranet

Normalizer

Monitor

Exchangeof controlinformation

Figure2: Typical locationsof normalizerandNIDS

A normalizerdiffers from a firewall in that its purposeis not to prevent accessto serviceson internal hosts,but to ensurethataccessto thosehoststakesplacein amannerthatis unambiguousto thesite’sNIDS.Figure2shows thetypical locationsof thenormalizerrelative totheNIDS andtheend-systemsbeingmonitored.Wewillrefer to traffic traveling from the “Internet” to the “In-tranet”asinbound, andto traffic in theotherdirectionasoutbound.

The basic idea of traffic normalizationwas simulta-neously inventedin the form of a protocol scrubber[8, 13, 17]. Thediscussionof theTCP/IPscrubberin [8]focuseson ambiguousTCP retransmissionattacksliketheonedescribedabove. Thekey distinctionsbetweenourwork andTCP/IPscrubbersis thatweattemptto de-velopa systematicapproachto identifying all potential

normalizations(wefind morethan70,perAppendixA),andwe emphasizethe implicationsof variousnormal-izationswith regardto maintainingor erodingtheend-to-endtransportsemanticsdefinedby the TCP/IPpro-tocol suite. In addition, we attemptto defendagainstattackson the normalizeritself, both throughstateex-haustion,andthroughstatelossif theattackercancausethenormalizeror NIDS to restart(the“cold start” prob-lem,per � 4.1).

In thenext sectionwediscussotherpossibleapproachesfor addressingtheNIDS ambiguityproblem. In � 3 welook at a numberof tradeoffs in thedesignof a normal-izer, andin � 4 two importantpracticalconsiderations.� 5 first presentsa systematicapproachto discoveringpossibleambiguitiesin a protocolasseenby a networkanalyzerand then applies this approachto analyzingIP version4. In � 6 we presentexamplesof particularlyilluminatingnormalizationsfor TCP, includinganambi-guity problemthatnormalizationcannotsolve. We thendiscussin � 7 auser-levelnormalizercallednorm, whichour performancemeasurementsindicateshouldbeableto processabout100,000pkts/secif implementedin thekernel.

2 Other approaches

In this sectionwe briefly review otherpossiblewaysofaddressingtheproblemof NIDSevasion,toprovidegen-eralcontext for thenormalizerapproach.

Usea host-basedIDS. We caneliminateambiguitiesinthetraffic streamby runningtheintrusiondetectionsys-tem(IDS) on all of theend-systemhostsratherthanby(or in addition to) passively monitoringnetwork links.As the host IDS hasaccessto the protocolstateabovethe IP and transportstacks,it hasunambiguousinfor-mationasto how the hostprocessesthe packet stream.However, this approachis tantamountto giving up onnetwork intrusiondetection,asit losesthegreatadvan-tageof beingabletoprovidemonitoringfor anentiresitecheaply, by deploying only a few monitorsto watchkeynetwork links. Host-basedsystemsalsopotentiallyfacemajordeploymentandmanagementdifficulties. In thiswork, we are concernedwith the questionof whetherpurelynetwork-basedIDS’scanremainviable,sowedonotconsiderthissolutionfurther.

Understand the details of the intranet. In principle,a NIDS can eliminatemuchof the ambiguity if it hasaccessto a sufficiently rich databasecatalogingthepar-ticulars of all of the end-systemprotocol implementa-tionsandthenetwork topology. A majorchallengewiththisapproachis whetherwecanindeedconstructsucha

database,particularlyfor a largesite.Perhapsaddinganactive probingelementto a NIDS cando so, andtherehasbeensomeinitial work in this regard[9]. However,anotherdifficulty is that theNIDS would needto knowhow to make useof the database—itwould requireamodelof everyvariantof everyOSandapplicationrun-ningwithin thesite,potentiallyanimmensetask.

Bifur cating analysis. Finally, in somecasestheNIDScanemploy bifurcatinganalysis[12]: if theNIDS doesnot know which of two possibleinterpretationstheend-systemmay apply to incoming packets, then it splitsits analysiscontext for that connectioninto multiplethreads,one for eachpossibleinterpretation,and ana-lyzeseachcontext separatelyfrom thenonwards.

Bifurcating analysisworks well whenthereareonly asmallnumberof possibleinterpretationsno matterhowmany packetsaresent.An examplewould bein thein-terpretationof the BACKSPACE vs. DELETE characterduring the authenticationdialog at the beginning of aTelnetconnection(beforetheuserhasanopportunitytoremapthemeaningof the characters):generally, eitherone or the other will deletethe characterof text mostrecentlytypedby theuser. TheNIDS canform two con-texts,oneinterpretingDELETE asthedeletioncharacter,and the other interpretingBACKSPACE as the deletioncharacter. Sincethe end-systemwill be in onestateortheother, oneof theanalysiscontexts will becorrectattheNIDS nomatterhow many packetsaresent.

However, bifurcatinganalysiswill notbesuitableif eacharriving ambiguouspacket requiresanadditionalbifur-cation, as in this casean attacker (or an inadvertentspateof “crud”) cansenda streamof packetssuchthatthenumberof analysiscontextsexplodesexponentially,rapidly overwhelmingthe resourcesof the NIDS. Con-sider, for example,theattackshown in Figure1. If theNIDS bifurcatesits analysison receiptof eachpoten-tially ambiguouspacket, it will rapidly requirea greatdealof stateandmany analysisthreads.Onceit hasseentheeightpacketsshown, it will needthreadsfor thepos-sibletext root, nice, rice, noot, niot, roce, roct, etc. �����

3 Normalization Tradeoffs

Whendesigninga traffic normalizer, we arefacedwitha setof tradeoffs, which canbe arrangedalongseveralaxes:

extentof normalizationvs.protectionimpactonend-to-endsemantics(servicemodels)impactonend-to-endperformanceamountof stateheldwork offloadedfrom theNIDS

Generallyspeaking,as we increasethe degreeof nor-malizationandprotection,we needto hold morestate;performancedecreasesboth for the normalizerandforend-to-endflows; andwe impactend-to-endsemanticsmore.Ourgoalis notto determineasingle“sweetspot,”but to understandthecharacterof thetradeoffs,and,ide-ally, designa systemthata sitecantuneto matchtheirlocal requirements.

Normalization vs. protection. As a normalizeris a“bump in the wire,” the samebox performingnormal-ization canalsoperformfirewall functionality. For ex-ample,a normalizercanpreventknown attacks,or shutdown accessto internalmachinesfrom anexternalhostwhentheNIDS detectsa probeor anattack.In this pa-perwe concentratemainly on normalizationfunctional-ity, but will occasionallydiscussprotectivefunctionalityfor whicha normalizeris well suited.

End-to-endsemantics.As muchaspossible,wewouldlikeanormalizerto preservetheend-to-endsemanticsofwell-behavednetworkprotocols,whilst cleaningupmis-behaving traffic. Somepacketsarrivingatthenormalizersimplycannotbecorrectaccordingto theprotocolspec-ification, andfor thesethereoften is a clearnormaliza-tion to apply. For example,if two copiesof anIP frag-mentarrive with thesamefragmentoffset,but contain-ing differentdata,thendroppingeitherof thefragmentsor droppingthewholepacket won’t underminethecor-rect operationof the particularconnection.Clearly theoperationwasalreadyincorrect.

However, thereare other packets that, while perfectlylegal accordingto the protocolspecifications,maystillcauseambiguitiesfor theNIDS. For example,it is per-fectly legitimatefor a packet to arrive at thenormalizerwith a low TTL. However, per thediscussionin the In-troduction,theNIDS cannotbesurewhetherthepacketwill reachthedestination.A possiblenormalizationforsuchpacketsis to increaseits TTL to a largevalue.1 Formosttraffic, this will have no adverseeffect, but it willbreakdiagnosticssuchastraceroute, which rely onthesemanticsof theTTL field for theircorrectoperation.

Normalizationslike these,which erodebut do not bru-tally violate the end-to-endprotocolsemantics,presenta basictradeoff thateachsitemustweighasanindivid-ual policy decision,dependingon its usercommunity,performanceneeds,andthreatmodel.In ouranalysisofdifferent normalizations,we placeparticularemphasison this tradeoff, becausewe believe the long-termutil-ity of preservingend-to-endsemanticsis oftenunderap-preciatedandat risk of beingsacrificedfor short-term

1Clearly, this is dangerousunlessthere is no possibility of thepacket loopingaroundto thenormalizeragain.

expediency.

Impact on end-to-end performance. Somenormal-izationsareperformedby modifying packets in a waythat removesambiguities,but alsoadverselyaffectstheperformanceof theprotocolbeingnormalized.Thereisnoclearanswerasto how muchimpactonperformancemight beacceptable,asthis clearlydependson thepro-tocol, localnetwork environment,andthreatmodel.

Stateholding. A NIDS systemmust hold statein or-der to understandthe context of incominginformation.Oneform of attackon a NIDS is a stateholdingattack,wherebythe attacker createstraffic that will causetheNIDS to instantiatestate(see � 4.2 below). If this stateexceedstheNIDS’sability tocope,theattackermaywellbeableto launchanattackthatpassesundetected.Thisis possiblein part becausea NIDS generallyoperatespassively, andso“f ailsopen.”

A normalizeralsoneedsto holdstateto correctambigu-ities in the dataflows. Suchstatemight involve keep-ing trackof unacknowledgedTCPsegments,or holdingIP fragmentsfor reassemblyin the normalizer. How-ever, unlike theNIDS, thenormalizeris in theforward-ing path,andsohasthecapabilityto “f ail closed”in thepresenceof stateholdingattacks.Similarly, thenormal-izer can perform “triage” amongstincoming flows: ifthenormalizeris nearstateexhaustion,it canshutdownanddiscardstatefor flows thatdonotappearto bemak-ing progress,whilst passingandnormalizingthosethatdo make progress.Theassumptionhereis thatwithoutcomplicity from internalhosts(seebelow), it is difficultfor anattacker to fake a largenumberof activeconnec-tionsandstressthenormalizer’sstateholding.

But evengiventheability to performtriage,if anormal-izeroperatesfail-closedthenwemusttakecareto assessthe degreeto which an attacker can exploit statehold-ing to launchadenial-of-serviceattackagainstasite,byforcingthenormalizerto terminatesomeof thesite’s le-gitimateconnections.

Inbound vs. outbound traffic. The designof the Bronetwork intrusion detectionsystemassumesthat it ismonitoringa bi-directionalstreamof traffic, andthatei-ther the sourceor the destinationof the traffic can betrusted[12]. However it is equallyeffectiveat detectinginboundor outboundattacks.

Theadditionof a normalizerto thescenariopotentiallyintroducesan asymmetrydue to its location—thenor-malizerprotectsthe NIDS againstambiguitiesby pro-cessingthetraffic beforeit reachestheNIDS (Figure2).Thus,an internalhostattemptingto attackan external

hostmight beableto exploit suchambiguitiesto evadethe local NIDS. If thesite’s threatmodelincludessuchattacks,eithertwo normalizersmaybeused,oneon ei-thersideof theNIDS, or aNIDS integratedinto asinglenormalizer. Finally, wenotethatif bothinternalandex-ternalhostsin a connectionarecompromised,thereislittle any NIDS or normalizercando to preventtheuseof encryptedor otherwisecovert channelsbetweenthetwo hosts.

Whilst anormalizerwill typically makemostof its mod-ificationsto incomingpackets,theremayalsobeanum-ber of normalizationsit applies to outgoing packets.Thesenormalizationsareto ensurethat theinternalandexternalhosts’protocolstatemachinesstayin stepde-spitethenormalizationof theincomingtraffic. It is alsopossibleto normalizeoutgoingtraffic to prevent unin-tendedinformationabouttheinternalhostsfrom escap-ing ([17], andsee� 5.1below).

Protection vs. offloading work. Althoughtheprimarypurposeof a normalizeris to preventambiguoustrafficfrom reachingtheNIDS whereit wouldeithercontributeto a stateexplosionor allow evasion,a normalizercanalsoserve to offloadwork from theNIDS. For example,if thenormalizerdiscardspacketswith badchecksums,then the NIDS needn’t spendcycles verifying check-sums.

4 Real-world Considerations

Dueto theadversarialnatureof attacks,for securitysys-temsit is particularlyimportantto considernot only theprinciplesby which the systemoperates,but as muchaspossiblealsothe“real world” detailsof operatingthesystem.In this section,we discusstwo suchissues,the“cold start”problem,andattackerstargetingthenormal-izer’soperation.

4.1 Cold start

It is naturalwhendesigninga network traffic analyzerto structureits analysisin termsof trackingtheprogres-sionof eachconnectionfrom thenegotiationto begin it,throughthe connection’s establishmentanddatatrans-fer operations,to its termination.Unlesscarefullydone,however, sucha designcan prove vulnerableto incor-rectanalysisduringa cold start. That is, whentheana-lyzerfirst beginsto run,it is confrontedwith traffic fromalready-establishedconnectionsfor which the analyzerlacksknowledgeof theconnectioncharacteristicsnego-tiatedwhentheconnectionswereestablished.

For example,the TCP scrubber[8] requiresa connec-

tion to go throughthenormalstart-uphandshake. How-ever, if a valid connectionis in progress,andthescrub-berrestartsor otherwiselosesstate,thenit will terminateany connectionsin progressat thetimeof thecoldstart,sinceto its analysistheir traffic exchangesappearto vio-latetheprotocolsemanticsthatrequireeachnewly seenconnectionto begin with astart-uphandshake.

The cold-startproblemalsoaffects the NIDS itself. IftheNIDS restarts,the lossof statecanmeanthatprevi-ouslymonitoredconnectionsareno longermonitorablebecausethestatenegotiatedat connectionsetuptime isno longer available. As we will show, techniquesre-quiredto allow cleannormalizerrestartscanalsohelpaNIDS with coldstart ( � 6.2).

Finally, wenotethatcoldstartis notanunlikely “cornercase”to dealwith, but insteadanon-goingissuefor nor-malizersandNIDSalike. First,anattackermightbeableto forcea cold startby exploiting bugsin eithersystem.Second,from operationalexperiencewe know thatonecannotavoid occasionallyrestartinga monitor system,for exampleto reclaimleakedmemoryor updateconfig-urationfiles. Accordingly, a patientattacker who keepsaconnectionopenfor a longperiodof timecanensureahighprobabilitythatit will spanacoldstart.

4.2 Attacking the Normalizer

Inevitably wemustexpectthenormalizeritself to bethetarget of attacks. Besidescompletesubversion,whichcanbe preventedonly thoughgooddesignandcodingpractice,two otherwaysa normalizercanbe attackedarestateholdingattacksandCPUoverloadattacks.

Stateholding attacks. Somenormalizationsarestate-less.For example,theTCPMSSoption(MaximumSeg-mentSize) is only allowed in TCP SYN packets. If anormalizerseesa TCPpacket with anMSSOptionbutno SYN flag, then this is illegal; but even so, it maybeunclearto the NIDS what the receiving hostwill dowith theoption,sinceits TCPimplementationmight in-correctlystill honorit. Becausetheuseof theoption isillegal, the normalizercansafelyremove it (andadjustthe TCP checksum)without needingto instantiateanystatefor thispurpose.

Other normalizationsrequire the normalizer to holdstate.For example,anattacker cancreateambiguitybysendingmultiple copiesof an IP fragmentwith differ-entpayloads.While a normalizercanremovefragment-basedambiguitiesby reassemblingall fragmentedIPpackets itself before forwarding them (and if neces-saryre-fragmentingcorrectly),to dothis,thenormalizermusthold fragmentsuntil they canbereassembledinto

a completepacket. An attacker canthuscausethenor-malizerto useup memoryby sendingmany fragmentsof packetswithout ever sendingenoughto completeapacket.

This particularattackis easilydefendedagainstby sim-ply boundingthe amountof memorythat can be usedfor fragments,andculling theoldestfragmentsfrom thecacheif thefragmentcachefills up. Becausefragmentstendto arrive together, thissimplestrategy meansanat-tacker hasto flood with a very high rateof fragmentsto causea problem. Also, asIP packetsareunreliable,there’snoguaranteethey arriveanyway, sodroppingtheoccasionalpacket doesn’t breakany end-to-endseman-tics.

More difficult to defendagainstis an attacker causingthenormalizerto hold TCPstateby floodingin, for ex-ample,thefollowing ways:

1. Simple SYN flooding with SYNs for multipleconnectionsto thesameor to many hosts.

2. ACK flooding. A normalizerreceiving a packetfor which it has no statemight be designedtotheninstantiatestate(in orderto addressthe“coldstart”problem).

3. Initial window flooding. The attacker sendsaSYN to aserver thatexists,receivesaSYN-ACK,and then floods data without waiting for a re-sponse.A normalizerwouldnormallytemporarilystoreunacknowledgedtext to preventinconsistentretransmissions.

Our strategy for defendingagainst theseis twofold.First, thenormalizerknowswhetheror not it’sunderat-tackby monitoringtheamountof memoryit is consum-ing. If it’s not underattack,it caninstantiatewhateverstateit needsto normalizecorrectly. If it believesit’sunderattack,it takesamoreconservativestrategy thatisdesignedto allow it to survive,althoughsomelegitimatetraffic will seedegradedperformance.

In generalouraimwhenunderattackis to only instanti-ateTCPconnectionstatewhenweseetraffic from anin-ternal(andhencetrusted)host,asthisrestrictsstatehold-ing attackson thenormalizerto thoseactuallyinvolvingrealconnectionsto internalhosts.Noteherethatthenor-malizeris explicitly not attemptingto protectthe inter-nal hostsfrom denial-of-serviceattacks;only to protectitself andtheNIDS.

CPU overload attacks. An attacker may alsoattemptto overloadthe CPU on the normalizer. However, un-likestateholdingattacks,suchanattackcannotcausethe

normalizerto allow anambiguityto pass.Instead,CPUoverloadattackscanmerelycausethenormalizerto for-wardpacketsata slower ratethanit otherwisewould.

In practice,we find thatmostnormalizationsarerathercheapto perform( � 7.2),sosuchattacksneedto concen-trateon the normalizationswherethe attacker canuti-lize computationalcomplexity to their advantage.Thus,CPU utilization attackswill normally needto be com-bined with stateholdingattacksso that the normalizerperformsanexpensivesearchin a largestate-space.Ac-cordingly, we needto pay greatattentionto the imple-mentationof suchsearchalgorithms,with extensiveuseof constant-complexity hashalgorithmsto locatematch-ing state.An additionaldifficulty thatarisesis theneedto beopportunisticaboutgarbagecollection,andto ap-ply algorithmsthatarelow costat thepossibleexpenseof not beingcompletelyoptimal in the choiceof statethatis reclaimed.

5 A SystematicApproach

ForanormalizertocompletelyprotecttheNIDS,in prin-ciple we mustbe able to normalizeevery possiblese-quenceof packetsthat theNIDS might treatdifferentlyfrom theend-system.Given that theNIDS cannotpos-sibly know all the applicationstateat the end-systemfor all applications,we focusin this work on the moretractableproblemof normalizingthe internetwork (IP,ICMP) andtransport(TCP, UDP) layers.

Evenwith this somewhatmorerestrictedscope,we findtherearestill a very large numberof possibleprotocolambiguitiesto address. Consequently, it behoovesusto developa systematicmethodologyfor attemptingtoidentify andanalyzeall of the possiblenormalizations.Themethodologyweadoptis to walk throughthepacketheadersof eachprotocolwe consider. This ensuresthatwe haveanopportunityto considereachfacetof these-manticsassociatedwith theprotocol.

For eachheaderelement,we considerits possiblerangeof values,their semantics,andwaysan attacker couldexploit the differentvalues;possibleactionsa normal-izer might take to thwart the attacks;and the effectstheseactionsmighthaveontheprotocol’send-to-endse-mantics.Whilst our primary intentionis to explore thepossibleactionsa normalizercantake, theexercisealsoraisesinterestingquestionsaboutthe incompletenessofthespecificationsof errorhandlingbehavior in Internetprotocols,andaboutthenatureof theintentionalandun-intentionalend-to-endsemanticsof Internetprotocols.

For reasonsof space,we confineour analysishereto a

singleprotocol;wepick IP (version4) becauseit is sim-ple enoughto cover fairly thoroughlyin this paper, yethasrich enoughsemantics(especiallyfragmentation)toconvey the flavor of morecomplicatednormalizations.In � 6 we thenpresentsomeparticularly illuminatingexamplesof TCPnormalizations.We deferourmethod-ical analysisof TCP(andUDPandICMP) to [4].

Notethatmany of thenormalizationswe discussbelowappearto addressveryunlikely evasionscenarios.How-ever, we believe theright designapproachis to normal-ize everythingthatwe canseehow to correctlynormal-ize,becausepacketmanipulationandsemanticambigu-ity is sufficiently subtlethatwe maymissanattack,butstill thwart it becausewe normalizedaway the degreesof freedomto expresstheattack.

Figure3 shows the fields of the IP packet header. Foreachfield we identify possibleissuesthatneednormal-izationanddiscusstheeffectsof oursolutionsonend-to-endsemantics.Thereaderpreferringto delve into onlymore interestingnormalizationsmay chooseto jumpaheadto � 5.1.

Version. A normalizershouldonly passpacketswith IPversionfieldswhich theNIDS understands.

Header length. It maybepossibleto sendapacket withan incorrect headerlength field that arrives at an end-systemsandisaccepted.However, otheroperatingsystemsor internalroutersmaydiscardthepacket. ThustheNIDSdoesnotknow if thepacket will beprocessedor not.Solution: If the headerlengthfield is lessthan20 bytes,the headeris incomplete,and the packet shouldbe dis-carded.If theheaderlengthfieldexceedsthepacket length,thepacketshouldbediscarded.(SeeTotal lengthbelow foradiscussionof exactlywhatconstitutesthepacket length.)Effect on semantics:Packet is ill-formed—noadverseef-fect.Note: If the headerlength is greaterthan 20 bytes, thisindicatesoptionsarepresent.SeeIP optionprocessingbe-low.

TypeOf Service/Diffserv/ECN. These bits have re-cently beenreassignedto differentiatedservices[11] andexplicit congestionnotification[15].

Issue: The Diffserv bits might potentially be used todeterministicallydrop a subsetof packets at an internalDiffserv-enabledrouter, for exampleby sendingburstsofpacketsthatviolatetheconditioningrequiredby theirDiff-servclass.Solution: If thesitedoesnotactuallyuseDiffservmecha-nismsfor incomingtraffic, clearthebits.Effect on semantics: If Diffserv is not beingusedinter-nally, the bits shouldbe zeroanyway, so zeroingthemissafe.Otherwise,clearingthembreaksuseof Diffserv.

001 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 11 2 3

Version Head len TOS/Diffserv/ECN Total Length

IP Identifier DFMF0 Fragment Offset

Time to Live Protocol Header Checksum

Source Address

Destination Address

Options Padding

Figure3: IP v4 Header

Issue: Somenetwork elements(such as firewalls) maydrop packetswith the ECN bits set,becausethey arenotyetcognizantof thenew interpretationof theseheaderbits.Solution: Clearthebits for all connectionsunlessthecon-nectionpreviously negotiateduseof ECN. Optionally, re-moveattemptsto negotiateuseof ECN.Effect on semantics: For connectionsthat have not ne-gotiateduseof ECN, no end-to-endeffect. Removing at-temptednegotiationof ECNwill preventconnectionsfrombenefitingfrom avoiding packet drops in somecircum-stances.

Total length. If thetotal lengthfield doesnot matchtheactualtotal lengthof the packet as indicatedby the linklayer, thensomeend-systemsmaytreatthepacketasbeingonelength,somemaytreatit asbeingtheother, andsomemaydiscardthepacket.Solution: Discardpacketswhoselengthfieldexceedstheirlink-layer length. Trim packets with longer link-layerlengthsdown to just thosebytesindicatedby the lengthfield.Effect on semantics: None,only ill-formed packets aredropped.

IP Identifier. See 5.1.

Must BeZero. TheIP specificationrequiresthat thebitbetween“IP Identifier” and“DF” mustbezero.Issue: If the bit is set, thenintermediaryor end-systemsprocessingthepacket mayor maynotdiscardit.Solution: Clearthebit to zero.Effect on semantics: None, sincethe bit is alreadyre-quiredto bezero.Note: We might think that we could just aswell discardthepacket, sinceit violatestheIP specification.Theben-efit of merelyclearingthebit is that if in thefuturea newusefor thebit is deployed,thenclearingthebit will permitconnectionsto continue,ratherthanabruptlyterminatingthem,in keepingwith the philosophythat Internetproto-cols shoulddegradegraduallyin the presenceof difficul-ties.

Don’t Fragment (DF) flag. If DF is set,andthe Maxi-mum TransmissionUnit (MTU) anywherein the internalnetwork is smaller than the MTU on the accesslink tothesite,thenanattacker candeterministicallycausesomepackets to fail to reachend-systemsbehind the smallerMTU link. This is doneby settingDF on packets witha largerMTU thanthelink.Note: The NIDS might be able to infer this attackfromICMP responsessentby therouterthatdropsthepackets,but theNIDS needsto holdstateto do so,leadingto state-holding attackson the NIDS. Also, it is not certainthattheNIDS will alwaysseetheICMP responses,dueto rate-limiting andmulti-pathing.Solution: ClearDF on incomingpackets.Effect on semantics: Breaks“Path MTU Discovery.” Ifanincomingpacket is too largefor aninternallink, it willnow befragmented,whichcouldhaveanadverseeffectonperformance—intherouterperformingthefragmentation,in theendhostperformingreassembly, or dueto increasedeffective packet lossrateson thenetwork links after frag-mentationoccurs[6]. That said, for many network envi-ronments,theseareunlikely to beseriousproblems.

Issue: Packetsarriving with DF setanda non-zerofrag-mentationoffset are illegal. However, it is not clearwhethertheend-systemwill discardthesepackets.Solution: Discardsuchpackets.Effect on semantics:None,ill-formed packet.

Mor eFragments(MF) flag , Fragment Offset.We treatthesetwo fields togetherbecausethey areinter-pretedtogether. An ambiguityarisesif theNIDS seestwofragmentsthat overlapeachotheranddiffer in their con-tents.As notedin [14], differentoperatingsystemsresolvetheambiguitydifferently.Solution: Reassembleincomingfragmentsin thenormal-izer ratherthanforwardingthem. If required,re-fragmentthe packet for transmissionto the internalnetwork if it islargerthantheMTU.Effect on semantics:Reassemblyis a valid operationfora routerto perform,althoughit is notnormallydone.Thusthisdoesnotaffectend-to-endsemantics.Note: A normalizerthat reassemblesfragmentsis vulner-able to stateholdingattacks,and requiresan appropriatetriagestrategy to discardpartially reassembledpackets ifthenormalizerstartsto runoutof memory.

Issue:Packetswherethelengthplusthefragmentationoff-setexceeds65535areillegal. They mayor maynotbeac-ceptedby theendhost.They mayalsocausesomehoststocrash.Solution: Drop thepackets.Effect on semantics:Packet is ill-formed, sono effect.

TTL (Time-to-live). As with DF, an attacker can useTTL to manipulatewhichof thepacketsseenby theNIDSreachestheend-system,perthediscussionfor Figure1.Solution #1: In principle,aNIDS couldmeasurethenum-berof hopsto every endhost,andignorepacketsthatlacksufficient TTL. In practice,though,at many sitesthis re-quiresholding a large amountof state,and it is possiblethattheinternalroutingmaychange(possiblytriggeredbytheattacker in someway) leaving awindow of timewheretheNIDS’smeasurementis incorrect.Solution #2: The NIDS may also be able to seeICMPtime-exceeded-in-transitpackets elicited by the attack.However, ICMP responsesareusuallyratelimited, so theNIDS may still not be able to tell exactly which packetswerediscarded.Solution #3: Configurethe normalizerwith a TTL thatis larger thanthe longestpathacrossthe internalsite. Ifpacketsarrive that have a TTL lower thanthe configuredminimum,thenthenormalizerrestorestheTTL to themin-imum.Effect on semantics: First, if a routing loop passesthroughthenormalizer, thenit maybe possiblefor pack-etsto loop forever, rapidly consumingtheavailableband-width. Second,restoringTTL will breaktraceroutedueto its useof limited-TTL packetsto discover forward-ing hops. Third, restoringTTL on multicastpacketsmayimpair theperformanceof applicationsthatuseexpandingring searches.The effect will be that all internalhostsinthegroupappearto be immediatelyinsidethenormalizerfrom thepointof view of thesearchalgorithm.

Protocol. Theprotocolfield indicatesthenext-layerpro-tocol, suchasTCPor UDP. Blocking traffic basedon it isa firewall function andnot a normalizerfunction. How-ever, an administratormaystill configurea normalizertodiscardpacketsthatdo not containwell-known protocols,suchasthosetheNIDS understands.

IP headerchecksum. Packetswith incorrectIP headerchecksumsmight possiblybe acceptedby end-hostswithdodgyIP implementations.Solution: In practicethis is not a likely scenario,but thenormalizercandiscardthesepacketsanyway, whichavoidstheNIDS needingto verify checksumsitself.Effect on semantics: Normally, no effect. However, itmightbepossibleto usecorruptedpacketsto gatherinfor-mationon link errorsor to signalto TCP not to backoffbecausethe lossis dueto corruptionandnot congestion.But sincerouterswill normallydiscardpacketswith incor-rectIP checksumsanyway, theissueis likely moot.

Sourceaddress. If thesourceaddressof anIP packet isinvalid in someway, thentheend-hostmayor maynotdis-card the packet. Examplesare127.0.0.1 (localhost),0.0.0.0 and255.255.255.255 (broadcast),multi-cast(classD) andclassE addresses.Solution: Drop thepacket.Effect on semantics:None,packet is ill-formed.Note: If theincomingpacket hasa sourceaddressbelong-ing to a known internalnetwork, thenormalizermight beconfiguredto drop the packet. This is morefirewall-typefunctionalitythannormalization,but will generallybede-sirable. However it would breakapplicationsthat rely on“sourcerouting” packetsvia anexternalhostandbackintothesite,suchasusingtraceroute to tracearoutefromanexternalsitebackinto the tracingsite. Also, if anout-goingpacket hasa sourceaddressthatdoesnot belongtoaknown internalnetwork, thenormalizermightbeconfig-uredto dropthepacket.

Destinationaddress. Likesourceaddresses,invalid des-tination addressesmight causeunexpectedbehavior atinternal hosts. Examplesare local broadcastaddresses(“smurf” attacks),the localhostand broadcastaddressesmentionedabove, and classE addresses(which are cur-rentlyunused).Solution: Drop the packet. In addition, the normalizershouldbecapableof droppingincomingpacketswith des-tinationaddressesthatwouldnotnormallyberoutedto thesite; thesemight appearasa resultof source-routing,andit is unclearwhateffect they might have on internalhostsor routers.Effect on semantics:None,destinationis illegal.

IP options. IP packetsmaycontainIP optionsthatmod-ify the behavior of internalhosts,or causepackets to beinterpreteddifferently.Solution: Remove IP optionsfrom incomingpackets.Effect on semantics: For end-to-endconnections,pre-sumablynone,as IP optionsshouldnot have effectsvis-ible at higherlayers;excepttheabsenceof anoptionmayimpair end-to-endconnectivity, for examplebecausetheconnectivity requiressourcerouting.For diagnosticstools,potentiallyserious.That said, the reality today is that optionsgenerallysuf-fer from poorperformancebecauseroutersdefertheirpro-cessingto the“slow path,” andmany sitesdisabletheiruseto countercertainsecurityrisks. Soin practice,removingIP optionsshouldhavelittle ill effect,otherthanthelossofsourceroutingfor diagnosingconnectivity problems.Thislastcanbeaddressed(ascanall semantictradeoffs associ-atedwith normalization)throughsite-specificpoliciescon-trolling thenormalizer’s operation.

Padding. Thepaddingfield at theendof a list of IP op-tions is explicitly ignoredby the receiver, so it is difficultto seethatit canbemanipulatedin any usefulway. Whileit doesprovideapossiblecovertchannel,sodomany otherheaderfields,andthwartingtheseis notanormalizertask.Solution: Zerothepaddingbytes,on theprinciplethatweperformnormalizationseven whenwe do not know of acorrespondingattack.Effect on semantics:None,field is explicitly ignored.

5.1 The IP Identifier and StealthPort Scans

TheIP identifier(ID) of outgoingpacketsmaygiveawayinformation about servicesrunning on internal hosts.This issueis not strictly a normalizerproblem,but thenormalizeris in a locationwell suitedto dealwith theissue.

One particular problem is the exceedingly deviousstealthport-scanningtechniquedescribedin [16, 18],which enablesanattacker to probetheservicesrunningon a remotehostwithout giving away the IP addressofthe host being usedto conductthe scan. Figure 4 il-lustratesthetechnique,whichwereview hereto develophow anormalizercanthwart it. Host � is theattacker, �is thevictim, and is thepatsy. Thepatsymustrun anoperatingsystemthat incrementsthe IP ID by one2 foreverypacket sent,no matterto whatdestination—manycommonoperatingsystemsusesucha“global” IP ID.

Host � continuallyexchangespacketswith host , ei-ther through a TCP transferor simply by pinging it.While doing this, the IP IDs of the responsesfrom to � normally incrementby onefrom onepacket to the

2Moregenerally, advancestheID field in apredictablefashion.

next. Now � fakesa TCP SYN to the port on � theywish to probe,andthey fake the sourceaddressof thepacketasbeingfrom .

If thereis no servicelisteningon the port, � sendsaRSTto . As hasno associatedconnectionstate, ignorestheRST, andthereis no effect on the IP IDs ofthestreamof packetsfrom to � .

A�

P V�

Echo request

reply, ID=3

Echo request

Echo request

Echo request

Echo request

Echo request

Echo request

reply, ID=4

reply, ID=5

reply, ID=6

reply, ID=7

reply, ID=9

reply, ID=10

TCP SYN, src=P, dst port=24�

TCP RST�

TCP SYN, src=P, dst port=25�

TCP SYN−ACK�

+1

+1

+1

+1

+1

+1

+2TCP RST, ID=8�

no listener

listener�exists!

no listeneron port 24,RST generated

listener�exists on port 25,SYN−ACK generated.

P has no state for thisconnection, so generatesa RST, which incrementsthe IP ID sequence

ttacker atsy ictim

Figure4: StealthPortScan

However, if thereis a servicelisteningon the port, �sendsa SYN-ACK to to completethe connection,ratherthanaRST. hasnostatefor thisconnection,andpromptlysendsaRSTbackto � . In sodoing,theglobalID sequenceon increasesby one;consequently, in thestreamof packetsfrom to � , the attacker observesastepof two (ratherthanone)in the ID sequence,sinceit missedoneof thepacketssentby , namelytheRSTfrom to � .

Thus andnot � appearsto bethehostconductingtheport-scan,whereasin fact it is completelyinnocent. �never seesa packet with a sourceof � . If � choosesadifferentpatsyfor everyport it wishesto check,thenthisport scanis veryhardto detect.

Thesolutionfor patsiesis for the normalizerto scram-ble (in a cryptographicallysecure,but reversiblefash-ion) theIP IDs of incomingandoutgoingpackets.Thispreventsinternal hostsfrom being usedas patsiesforsuchscans.Theeffectonsemanticsis thatany diagnos-tic protocolthat reportsthe IP IDs of incomingpacketsbackto thesendermaybreak.ICMP messagescanstillfunction if the normalizerappliesthe unscramblingtotheembeddedID fieldsthey carry.

The solution for victims is to use the “reliable RST”technique(see� 6.1below). Thenormalizertransmitsa“keep-alive” acknowledgment(ACK) packetbehindev-ery RST packet it forwardsout of the site. When theACK arrivesatthepatsy, thepatsywill replywith aRST,just asit doesin theSYN-ACK case.Consequently, theIP ID sequenceasseenby theattackerwill jumpby twoin both cases,whetherthe victim is running the givenserviceor not.

Sendingkeep-alives for reliable RSTsgeneratesextratraffic, but hasno effect on end-to-endsemantics,sincethekeep-alive ACK following theRSTis guaranteedtobe either rejectedby the victim (if it first received theRST)or ignored(if theRSTwaslostandtheconnectionremainsopen).

6 Examplesof TCP Normalizations

We appliedthesame“walk theheader”methodologyasin the previoussectionto TCP, UDP, andICMP. How-ever, dueto spacelimitationswedeferthedetailedanal-ysis to [4], andin this sectionfocuson threeexamplesfor TCP that illuminate differentnormalizationissues:reliableRSTs,cold start for TCP, andan exampleof aTCPambiguitythatanormalizercannotremove.

6.1 ReliableRSTs

With TCP, the control signalsfor connectionestablish-mentandcompletion(SYN andFIN, respectively) aredeliveredreliably, but the “abrupt termination” (RST)signal is not. This leadsto a significantproblem: ingeneral,both a normalizerand a NIDS needsto teardown statefor anexisting connectiononcethatconnec-tion completes,in orderto recover theassociatedmem-ory. But it is not safeto do so uponseeinga RST, be-causethe RST packet might be lost prior to arriving atthereceiver, or mightberejectedby thereceiver.

Thus,a monitor cannottell whethera given RST doesin fact terminateits correspondingconnection. If themonitorerrsandassumesit doeswhenin factit did not,thenanattackercanlatercontinuesendingtraffic on theconnection,andthemonitorwill lackthenecessarystate(namely, thattheconnectionis still established,andwithwhatsequencenumbers,windows,etc.) to correctlyin-terpretthattraffic. On theotherhand,if themonitoras-sumestheRSTdoesnot terminatetheconnection,thenitis left holdingthecorrespondingstatepotentiallyindef-initely. (Unfortunately, RST-terminationis not uncom-monin practice,soevenfor benigntraffic, thisstatewillgrow significantlyover time.)

TheRST might fail to arrive at the receiver becauseofnormal lossprocessessuchasbuffer overflows at con-gestedrouters,or becauseof manipulationby an at-tacker, suchastheTTL gamesdiscussedin thecontextof Figure1. In addition,therulesappliedby receiverstodeterminewhethera particularRSTis valid vary acrossdifferentoperatingsystems,which theNIDS likely can-not track.

A generalsolution to this problemwould be to ensurethat RSTsare indeeddeliveredand accepted,i.e., wewant“reliableRSTs.” We cando so,asfollows. When-ever the normalizerseesa RST packet sentfrom � to�

, afternormalizingit andsendingit on, it synthesizesasecondpacketandsendsthatto

�, too. Thisadditional

packet takestheform of a TCP“keep-alive,” which is adataless3 ACK packet with a sequencenumberjust be-low the point cumulatively acknowledgedby

�. The

TCPspecificationrequiresthat�

mustin turn reply tothekeep-alivewith anACK packetof its own, onewiththecorrectsequencenumberto beacceptedby � , to en-surethatthetwo TCPpeersaresynchronized.However,�

only doesthis if the connectionis still open;if it isclosed,it sendsaRSTin responseto thekeep-alive.

Thus,usingthis approach,thereare four possibleout-comeswhenever thenormalizerforwardsa RSTpacket(andtheaccompanying keep-alive):

(i) TheRSTwasacceptedby�

, andso�

will gen-erateanotherRST backto � uponreceiptof thekeep-alive;

(ii) theRSTeitherdid notmake it to�

, or�

ignoredit, in which case

�will generatean ACK in re-

sponseto thekeep-alive;

(iii) thekeep-alivedid not make it to�

, or�

ignoredit (thoughthis lattershouldn’t happen);

(iv) or, the response�

sentin reply to thekeep-alivewaslostbeforethenormalizercouldseeit.

Thenormalizerthenusesthefollowing rule for manag-ing its stateuponseeingaRST: uponseeinga RSTfrom� to

�, retain the connectionstate; but subsequently,

uponseeinga RSTfrom�

to � , tear downthe state.4

Thus,thenormalizeronly discardstheconnectionstateuponseeingproof that

�hasindeedterminatedthecon-

nection. Note that if either � or�

misbehaves, theschemestill works, becauseoneof the RSTswill still

3In practice,onesendsthe lastacknowledgedbyte if possible,forinteroperabilitywith olderTCPimplementations.

4Of coursewe do not senda keep-alive to make the secondRSTreliableor we’d initiateaRSTwar.

have beenlegitimate;only if � and�

colludewill theschemefail, and,asnotedearlier, in that casethereislittle a normalizeror a NIDS cando to thwartevasion.

Therule aboveaddressescase(i). For case(ii) , thenor-malizerneedn’t do anything special(it still retainstheconnectionstate,in accordancewith therule). For cases(iii) and (iv), it will likewise retain the state,perhapsneedlessly;but thesecasesshouldbe rare,andarenotsubjectto manipulationby � . They couldbecreatedby�

if�

is malicious;but not to mucheffect, as in thatcasetheconnectionis alreadyterminatedasfar as � isconcerned.

6.2 Cold start for TCP

Recallthatthe“cold start”problemconcernshow anor-malizershouldbehavewhenit seestraffic for a connec-tion that apparentlyexisted before the normalizerbe-gan its currentexecution( � 4.1). One particulargoalis that thenormalizer(andNIDS) refrain frominstanti-atingstatefor apparently-activeconnectionsunlesstheycandeterminethattheconnectionis indeedactive;other-wise,afloodof bogustraffic for avarietyof non-existentconnectionswould result in the normalizercreatingagreatdealof state,resultingin a state-holdingattack.

Accordingly, we needsomeway for the normalizertodistinguishbetweengenuine,pre-existing connections,andbogus,non-existentconnections,andto do so in astatelessfashion!

As with theneedin theprevioussectionto make RSTstrustworthy, we canagainusethetrick of encapsulatingtheuncertaintyin aprobepacketandusingthestateheld(or not held) at the receiver to inform the normalizer’sdecisionprocess.

Our approachis basedon the assumptionthat the nor-malizerlies betweena trustednetwork andanuntrustednetwork, andworks as follows. Upon seeinga packetfrom � to

�for which the normalizerdoesnot have

knowledgeof anassociatedconnection,if � is from thetrustednetwork, then the normalizerinstantiatesstatefor a correspondingconnectionandcontinuesasusual.However, if � is from the untrustednetwork, the nor-malizer transformsthe packet into a “keep-alive” bystrippingoff thepayloadanddecrementingthesequencenumberin the header. It then forwards the modifiedpacket to

�and forgetsaboutit. If thereis indeeda

connectionbetween� and�

, then�

will respondtothe keep-alive with an ACK, which will suffice to theninstantiatestatefor theconnection,since

�is from the

trustednetwork. If noconnectiondoesin factexist, then�will eitherrespondwith aRST, or notatall (if

�itself

doesnot exist, for example).In bothof thesecases,thenormalizerdoesnotwind up instantiatingany state.

The schemeworks in part becauseTCP is reliable: re-moving thedatafrom a packet doesnot breakthecon-nection,because� will work diligently to eventuallyde-liver thedataandcontinuetheconnection.

(Note that a similar schemecan also be appliedwhenthenormalizerseesaninitial SYN for anew connection:by only instantiatingstatefor theconnectionuponsee-ing aSYN-ACK from thetrustednetwork, theloadonanormalizerin thefaceof aSYN floodingattackis dimin-ishedto reflecttherateatwhichthetargetcanabsorbtheflood,ratherthanthefull incomingfloodingrate.)

Evenwith thisapproach,though,coldstartfor TCPstillincludessomesubtle,thorny issues. One in particularconcernsthewindowscalingoption thatcanbenegoti-atedin TCP SYN packetswhenestablishinga connec-tion. It specifiesa left-shift to be appliedto the 16 bitwindow field in the TCP header, in orderto permit re-ceiver windows of greaterthan 64 KB. In general,anormalizermust be able to tell whethera packet willbe acceptedat the receiver. Becausereceiverscandis-card packets with datathat lies beyond the boundsofthe receiver window, the normalizerneedsto know thewindow scalingfactorin orderto mirror thisdetermina-tion. However, uponcold start, the normalizercannotdeterminethe window scalingvalue,becausethe TCPendpointsno longerexchangeit, they just usethevaluethey agreeduponat connectionestablishment.

We know of no fully reliableway by which thenormal-izer might infer the window scalingfactorin this case.Consequently, if thenormalizerwishesto avoid thisam-biguity, it musteitherensurethatwindow scalingis sim-ply notused,i.e., it mustremovethewindowscaleoptionfromall TCPSYNpacketsto prevent its negotiation(orit musthave accessto persistentstateso it canrecoverthecontext for eachactiveconnectionunambiguously).

Doing so is not without a potentially significantcost:window scaling is requiredfor good performanceforconnectionsoperatingover long-haul,high-speedpaths[1], andsiteswith suchtraffic might in particularwantto disablethisnormalization.

More generally, this aspectof thecold startproblemil-lustrateshow normalizationscansometimescomequiteexpensively. The next sectionillustrateshow they aresometimessimplynotpossible.

6.3 Incompletenessof Normalization

In theabsenceof detailedknowledgeaboutthevariousapplications,normalizationswill tendto berestrictedtotheinternetwork andtransportlayers.However, evenatthetransportlevel anormalizercannotremoveall possi-ble ambiguities.For example,thesemanticsof theTCPurgent pointer cannotbe understoodwithout knowingthesemanticsof theapplicationusingTCP:

r o b o tURGENTpointer

0 1 2 3 4

If thesendersendsthe text “robot” with theTCPur-gentpointerset to point to the letter “b”, thenthe ap-plication may receive either “robot” or “root,” de-pendingon thesocket optionsenabledby the receivingapplication. Without knowledgeof the socket optionsenabled,thenormalizercannotcorrectlynormalizesuchapacketbecauseeitherinterpretationof it couldbevalid.

In thiscase,theproblemis likely notsignificantin prac-tice, becauseall protocolsof which we are aware ei-ther enableor disablethe relevant option for the entireconnection—sotheNIDS canusea bifurcatinganalysiswithout theattacker beingableto createanexponentialincreasein analysisstate. However, the examplehigh-lights that normalizers,while arguablyvery useful forreducingtheevasionopportunitiesprovidedby ambigu-ities,arenotanall-encompassingsolution.

7 Implementation

We have implementednorm, a fairly complete,user-level normalizerfor IP, TCP, UDP andICMP. Thecodecomprisesabout4,800 lines of C and useslibpcap[10] to capturepackets and a raw socket to forwardthem. We have currently testednorm underFreeBSDandLinux, andwill releaseit (andNetDuDE,seebelow)publicly in Summer2001via www.sourceforge.net.

Naturally, for highperformanceaproductionnormalizerwouldneedto run in thekernelratherthanat userlevel,but our current implementationmakes testing,debug-gingandevaluationmuchsimpler.

AppendixA summarizesthecompletelist of normaliza-tionsnormperforms,andthesearediscussedin detailin[4]. Herewe describeour processfor testingandevalu-atingnorm, andfind that theperformanceon commod-ity PChardwareis adequatefor deploymentatasitelikeourswith a bidirectional100Mb/saccesslink to theIn-ternet.

7.1 Evaluation methodology

In evaluatinga normalizer, wecareaboutcompleteness,correctness,andperformance.The evaluationpresentsachallengingproblembecauseby definitionmostof thefunctionalityof a normalizerappliesonly to unusualor“impossible” traffic, and the resultsof a normalizeringeneralare invisible to connectionendpoints(depend-ing on thedegreeto which the normalizationspreserveend-to-endsemantics).We primarily usea trace-drivenapproach,in whichwepresentthenormalizerwith anin-put traceof packetsto processasthoughit hadreceivedthem from a network interface,and inspectan outputtraceof the transformedpackets it in turn would haveforwardedto theotherinterface.

Eachindividualnormalizationneedsto betestedin iso-lation to ensurethat it behavesaswe intend. The firstproblemhereis to obtaintesttraffic thatexhibits thebe-havior wewish to normalize;oncethis is done,weneedto ensurethatnormcorrectlynormalizesit.

With someanomalousbehavior, we cancapturepackettracesof traffic that our NIDS identifiesas being am-biguous.Primarilythis is “crud” andnotrealattacktraf-fic [12]. We can also usetools suchas nmap[3] andfragrouter [2] to generatetraffic similar to that an at-tackermightgenerate.However, for mostof thenormal-izationswe identified,no real tracetraffic is available,andsowemustgenerateourown.

Figure5: UsingNetDuDEto createtesttraffic

To this end, we developedNetDuDE (Figure 5), theNetwork Dump DisplayerandEditor. NetDuDEtakeslibpcap packet tracefile,displaysthepacketsgraphi-cally, andallowsusto examineIP, TCP, UDP, andICMP

headerfields.5 In addition,it allowsusto edit thetrace-file, settingthe valuesof fields, addingand removingoptions,recalculatingchecksums,changingthe packetordering,andduplicating,fragmenting,reassemblingordeletingpackets.

To test a particularnormalization,we edit an existingtraceto createtheappropriateanomalies.We thenfeedthe tracefilethroughnorm to createa new normalizedtrace. We thenboth reexaminethis tracein NetDuDEto manuallycheckthat the normalizationwe intendedactuallyoccurred,andfeedthetracebackinto norm, toensurethatonasecondpassit doesnotmodify thetracefurther. Finally, we storetheinput andoutputtracefilesin ourlibraryof anomaloustracessothatwecanperformautomatedvalidationtestswhenever we make a changeto norm, to ensurethatchangingonenormalizationdoesnotadverselyaffectany others.

7.2 Performance

As mentionedabove, our current implementationofnorm runsat userlevel, but we areprimarily interestedin assessinghow well it might run asa streamlinedker-nel implementation,sinceit is reasonableto expectthata productionnormalizerwill merit a highly optimizedimplementation.

To addressthis,norm incorporatesa testmodewherebyit readsanentirelibpcap tracefile into memoryandin additionallocatessufficient memoryto storeall theresultingnormalizedpackets. It thentimeshow long ittakesto run, readingpacketsfrom onepool of memory,normalizingthem,andstoringthe resultsin thesecondmemorypool. After measuringthe performance,normwritesthesecondmemorypoolout to alibpcap tracefile, sowecanensurethatthetestdid in factmeasurethenormalizationswe intended.

Thesemeasurementsthusfactorout the costof gettingpacketsto thenormalizerandsendingthemoutoncethenormalizeris donewith them. For a user-level imple-mentation,this cost is high, as it involvescopying theentirepacket streamup from kernelspaceto userspaceandthenbackdown again;for a kernelimplementation,it shouldbelow (andwegiveevidencebelow thatit is).

For baselinetesting,weusethreetracefiles:

Trace T1: a 100,000packet tracecapturedfrom theInternetaccesslink at theLawrenceBerkeley Na-tional Laboratory, containingmostly TCP traf-fic (88%) with someUDP (10%), ICMP (1.5%),

5At thetimeof writing, ICMP supportis still incomplete.

andmiscellaneous(IGMP, ESP, tunneledIP, PIM;0.2%).Themeanpacketsizeis 491bytes.

Trace U1: a tracederived from T1, whereeachTCPheaderhasbeenreplacedwith aUDPheader. TheIP partsof thepacketsareunchangedfrom T1.

TraceU2: a100,000packettraceconsistingentirelyof92byteUDPpackets,generatedusingnetcat.

T1 givesus resultsfor a realisticmix of traffic; there’snothingparticularlyunusualaboutthis tracecomparedto the othercapturednetwork traceswe’ve tested. U1is totally unrealistic,but asUDP normalizationis com-pletelystatelesswith veryfew checks,it givesusabase-line numberfor how expensive the more streamlinedIP normalizationis, asopposedto TCP normalization,which includesmany morechecksand involvesmain-taining a control block for eachflow. TraceU2 is forcomparisonwith U1, allowing usto testwhatfractionoftheprocessingcostis per-packetasopposedto per-byte.

We performedall of our measurementson an x86 PCrunning FreeBSD4.2, with a 1.1GHz AMD AthlonThunderbirdprocessorand133MHzSDRAM.In abare-bonesconfigurationsuitablefor a normalizerbox, sucha machinecostsunderUS$1,000.

For aninitial baselinecomparison,weexaminehow fastnormcantake packetsfrom onememorypool andcopythemto theother, withoutexaminingthepacketsatall:

Memory-to-memorycopyonlyTrace pkts/sec bit rateT1,U1 727,270 2856Mb/sU2 1,015,600 747Mb/s

Enablingall thechecksthatnormcanperformfor bothinboundandoutboundtraffic6 examinesthecostof per-forming the testsfor the checks,even thoughmost ofthementailno actualpacket transformation,since(asinnormaloperation)mostfieldsdo not requirenormaliza-tion:

All checksenabledTrace pkts/sec bit rateT1 101,000 397Mb/sU1 378,000 1484Mb/sU2 626,400 461Mb/s

Numberof NormalizationsTrace IP TCP UDP ICMP TotalT1 111,551 757 0 0 112,308

6Normally fewer checkswouldbeenabledfor outboundtraffic.

Comparingagainstthe baselinetests, we seethat IPnormalizationis abouthalf the speedof simply copy-ing thepackets. Thelargenumberof IP normalizationsconsistmostly of simple actionssuchas TTL restora-tion, andclearingthe DF andDiffserv fields. We alsoseethatTCPnormalization,despiteholdingstate,is notvastlymoreexpensive, suchthat TCP/IPnormalizationis roughlyonequarterof the speedof UDP/IPnormal-ization.

Theseresultsdo not, of course,meanthat a kernelim-plementationforwardingbetweeninterfaceswill achievethesespeeds. However, the Linux implementationoftheclick modularrouter[7] canforward333,000smallpackets/secona700MHzPentium-III.Theresultsaboveindicatethat normalizationis cheapenoughthat a nor-malizerimplementedas(say)a click moduleshouldbeable to forward normal traffic at line-speedon a bi-directional100Mb/slink.

Furthermore,if the normalizer’s incoming link is at-tacked by flooding with small packets,we shouldstillhave enoughperformanceto sustainthe outgoinglinkat full capacity. Thuswe concludethat deploymentofthe normalizerwould not worsenany denial-of-serviceattackbasedon link flooding.

A morestressfulattackwouldbeto floodthenormalizerwith smallfragmentedpackets,especiallyif theattackergeneratesout-of-orderfragmentsandinterspersesmanyfragmentedpackets. Whilst a normalizerunderattackcanperformtriage,preferentiallydroppingfragmentedpackets,wepreferto only do thisasa lastresort.

To testthis attack,we took theT1 traceandfragmentedevery packet with an IP payloadlarger than 16 bytes:traceT1-frag comprisessome3 million IP fragmentswith a meansizeof 35.7bytes.Randomizingtheorderof thefragmentstreamover increasingintervalsdemon-stratestheadditionalwork thenormalizermustperform.For example,with minimal re-orderingthe normalizercan reassemblefragmentsat a rate of about 90Mb/s.However, if we randomizetheorderof fragmentsby upto 2,000packets,thenthenumberof packetssimultane-ously in the fragmentationcachegrows to 335 andthedataratewecanhandlehalves.

rnd input frag’ed output output pktsinintv’ l frags/s bit rate pkts/sec bit rate cache

100 299,67086Mb/s 9,989 39Mb/s 70500 245,64070Mb/s 8,188 32Mb/s 133

1,000 202,20058Mb/s 6,740 26Mb/s 2112,000 144,87041Mb/s 4,829 19Mb/s 335

It is clearthat in theworstcase,normdoesneedto per-

form triage,but that it candelaydoing so until a largefractionof thepacketsareverybadlyfragmented,whichis unlikely exceptwhenunderattack.

Theotherattackthatslows thenormalizernoticeablyiswhennorm hasto copewith inconsistentTCP retrans-missions.If we duplicateevery TCPpacket in T1, thenthisstressestheconsistency mechanism:

All checksenabledTrace pkts/sec bit rateT1 101,000 397Mb/sT1-dup 60,220 236Mb/s

Although the throughputdecreasessomewhat, the re-ductionin performanceis notgrave.

To conclude,a softwareimplementationof a traffic nor-malizerappearsto becapableof applyinga largenum-ber of normalizationsat line speedin a bi-directional100Mb/senvironmentusing commodityPC hardware.Sucha normalizeris robustto denial-of-serviceattacks,althoughin the specific caseof fragmentreassembly,very severeattacksmay requirethe normalizerto per-form triageon theattacktraffic.

Acknowledgments

We’d like to thankBill Fenner, BradKarp, Orion Hod-son,Yin Zhang,Kevin Fall, SteveBellovin andtheEnd-to-endResearchGroupfor their commentsandsugges-tions. Thanksalsogo to Jupiter’s in Berkeley and thefineGuinnessandLostCoastbrewing companiesfor lu-bricatingmany hoursof discussionon this topic.

References

[1] M. Allman, D. Glover andL. Sanchez,“Enhanc-ing TCP Over SatelliteChannelsusing StandardMechanisms,” RFC2488,Jan.1999.

[2] AnzenComputing,fragrouter, 1999.http://www.anzen.com/research/nidsbench/

[3] Fyodor, nmap, 2001.http://www.insecure.org/nmap/

[4] M. Handley, C.Kreibich,andV. Paxson,drafttech-nicalreport,to appearathttp://www.aciri.org/vern/papers/norm-TR-2001.ps.gz,2001.

[5] horizon <jmcdonal@unf.edu>, “DefeatingSniffersandIntrusionDetectionSystems”,PhrackMagazineVolume8, Issue54,Dec.25th,1998.

[6] C. KentandJ.Mogul, “FragmentationConsideredHarmful,” Proc.ACM SIGCOMM, 1987.

[7] E. Kohler, R. Morris, B. Chen, J. Jannotti andM.F. Kaashoek, “The Click modular router,”ACM Transactionson ComputerSystems, 18(3),pp.263–297,Aug. 2000.

[8] G.R.Malan,D. Watson,F. JahanianandP. Howell,“Transportand Application ProtocolScrubbing”,Proceedingsof theIEEEINFOCOM2000Confer-ence,Tel Aviv, Israel,Mar. 2000.

[9] L. Deri and S. Suin, “Improving Network Secu-rity UsingNtop,” Proc. Third InternationalWork-shopon the RecentAdvancesin Intrusion Detec-tion (RAID2000),Toulouse,France,Oct.2000.

[10] S.McCanne,C.LeresandV. Jacobson,libpcap,1994.ftp://ftp.ee.lbl.gov/libpcap.tar.Z

[11] K. Nichols,S.Blake,F. BakerandD. Black,“Def-inition of the DifferentiatedServicesField (DSField) in the IPv4 andIPv6 Headers”,RFC 2474,Dec.1998.

[12] V. Paxson, “Bro: A Systemfor DetectingNet-work Intruders in Real-Time”, Computer Net-works,31(23-24),pp.2435-2463,14Dec1999.

[13] V. Paxsonand M. Handley, “Defending AgainstNIDS Evasion using Traffic Normalizers,” pre-sented at Second International Workshop onthe Recent Advances in Intrusion Detection,Sept.1999.

[14] T. H. Ptacek and T. N. Newsham, “Insertion,Evasion and Denial of Service: Eluding Net-work Intrusion Detection”, Secure Networks,Inc., Jan.1998.http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps

[15] K. Ramakrishnanand S. Floyd, “A ProposaltoaddExplicit CongestionNotification(ECN)to IP”,RFC2481,Jan.1999.

[16] S. Sanfilippo, “new tcp scanmethod,” Bugtraq,Dec.18,1998.

[17] M. Smart,G.R. Malan and F. Jahanian,“Defeat-ing TCP/IPStackFingerprinting,” Proc. USENIXSecuritySymposium, Aug. 2000.

[18] M. deVivo, E. Carrasco,G. IsernandG. deVivo,“A Review of Port ScanningTechniques,” Com-puterCommunicationReview, 29(2),April 1999.

A Normalizations performed by norm

Our normalizer implementationnorm currently per-forms 54 of the following 73 normalizationswe iden-tified:

IP Normalizations

# IP Field NormalizationPerformed

1 Version Non-IPv4packetsdropped.2 HeaderLen Drop if hdr len toosmall.3 HeaderLen Drop if hdr len too large.4 Diffserv Clearfield.5 ECT Clearfield.6 Total Len Drop if tot len � link layerlen.7 Total Len Trim if tot len � link layerlen.8 IP Identifier EncryptID. �9 Protocol Enforcespecificprotocols.�– Protocol Passpacket to TCP,UDP,ICMP

handlers.10 Fragoffset Reassemblefragmentedpackets.11 Fragoffset Drop if offset+ len � 64KB.12 DF ClearDF.13 DF Drop if DF setandoffset � 0.14 Zeroflag Clear.15 Srcaddr Drop if classD or E.16 Srcaddr Drop if MSByte=127or 0.17 Srcaddr Drop if 255.255.255.255.18 Dst addr Drop if classE.19 Dst addr Drop if MSByte=127or 0.20 Dst addr Drop if 255.255.255.255.21 TTL RaiseTTL to configuredvalue.22 Checksum Verify, dropif incorrect.23 IP options RemoveIP options.�24 IP options Zeropaddingbytes.�� Indicatesnormalizationsplanned,but either not yet

implementedor notyet testedat thetimeof writing.

Notethatmostnormalizationsareoptional,accordingtolocalsitepolicy.

UDP Normalizations

# UDPField NormalizationPerformed

1 Length Drop if doesn’t matchlengthasindicatedby IP total length.

2 Checksum Verify, dropif incorrect.

TCP Normalizations

# TCPField NormalizationPerformed

1 SeqNum Enforcedataconsistency in re-transmittedsegments.

2 SeqNum Trim datato window.3 SeqNum Cold-start:trim to keep-alive.4 Ack Num DropACK abovesequencehole.5 SYN Removedataif SYN=1.6 SYN If SYN=1& RST=1,drop.7 SYN If SYN=1& FIN=1,clearFIN.8 SYN If SYN=0 & ACK=0 & RST=0,

drop.9 RST Removedataif RST=1.

10 RST MakeRSTreliable.11 RST Drop if not in window. �12 FIN If FIN=1 & ACK=0,drop.13 PUSH If PUSH=1& ACK=0,drop.14 HeaderLen Drop if lessthan5.15 HeaderLen Drop if beyondendof packet.16 Reserved Clear.17 ECE,CWR Optionallyclear.18 ECE,CWR Clearif notnegotiated.�19 Window Removewindow withdrawals.20 Checksum Verify, dropif incorrect.21 URG,urgent Zerourgentif URGnotset.22 URG,urgent Zeroif urgent � endof packet.23 URG If URG=1& ACK=0,drop.24 MSSoption If SYN=0,removeoption.25 MSSoption Cacheoption,trim datato MSS.26 WS option If SYN=0,removeoption.27 SACK pmt’d If SYN=0,removeoption.28 SACK opt Remove option if length

invalid.�29 SACK opt Remove if left edge of SACK

block � right edge.�30 SACK opt Removeif any blockabovehigh-

estseq.seen.�31 SACK opt Trim any block(s) overlapping

or continguousto cumulativeac-knowledgementpoint.�

32 T/TCPopts Remove if NIDS doesn’t sup-port.

33 T/TCPopts Removeif underattack.�34 TSoption Remove from non-SYN if not

negotiatedin SYN.�35 TSoption If packet failsPAWStest,drop.�36 TSoption If echoedtimestampwasn’t pre-

viouslysent,drop.�37 MD5 option If MD5 usedin SYN, dropnon-

SYN packetswithout it. �38 otheropts Removeoptions.

ICMP Normalizations

# ICMP Type NormalizationPerformed

1 Echorequest Dropif destinationis amulticastor broadcastaddress.

2 Echorequest Optionally drop if ping check-sumincorrect.

3 Echorequest Zero“code” field.4 Echoreply Optionally drop if ping check-

sumincorrect.5 Echoreply Drop if nomatchingrequest.�6 Echoreply Zero“code” field.7 Source

quenchOptionally drop to preventDoS.�

8 DestinationUnreachable

Unscramble embeddedscram-bledIP identifier. �

9 other Drop.�Thefollowing “transport”protocolsarerecognized,butcurrentlypassedthroughunnormalized:IGMP, IP-in-IP,RSVP, IGRP, PGM.