security assessment of the internet protocol

8/14/2019 Security Assessment of the Internet Protocol

http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 1/63

Security ASSeSSment

of the internet Protocol

july 2008



Written by Fernando Gont on behalf of CPNI.

Disclaimer

Reference to any specic commercial product, process or service by trade name, trademark manufacturer, or otherwise,

does not constitute or imply its endorsement, recommendation, or favouring by CPNI. The views and opinions of authors

expressed within this document shall not be used for advertising or product endorsement purposes.

To the fullest extent permitted by law, CPNI accepts no liability for any loss or damage (whether direct, indirect or

consequential and including, but not limited to, loss of prots or anticipated prots, loss of data, business or goodwill)

incurred by any person and howsoever caused arising from or connected with any error or omission in this document

or from any person acting, omitting to act or refraining form acting upon, or otherwise using, the information contained

in this document or its references. You should make your own judgement as regards to use of this document and seek

independent professional advice on your particular circumstances.

www.cpni.gov.uk



Security Assessment of the Internet Protocol

Table of Contents

1. Preface ..................................................................................................................................... 3

. Introduction ..................................................................................................................... 3

.2 Scope of this document .................................................................................................. 4

.3 Organization of this document ......................................................................................... 4

.4 Typographical conventions .............................................................................................. 5

.5 Getting the latest version of this document ....................................................................... 5

.6 Advice and guidance to vendors ...................................................................................... 5

.5 Acknowledgements ......................................................................................................... 5

2. The Internet Protocol .............................................................................................................. 6

3. Internet Protocol header elds .............................................................................................. 7

3. Version ............................................................................................................................. 7

3.2 IHL (Internet Header Length) ............................................................................................ 8

3.3 TOS ................................................................................................................................. 8

3.4 Total Length ..................................................................................................................... 9

3.5Identication(ID) ............................................................................................................. 0

3.5. Some workarounds implemented by the industry ........................................................ 0

3.5.2 Possible security improvements ..................................................................................

3.6 Flags .............................................................................................................................. 3

3.7 Fragment Offset ............................................................................................................. 4

3.8 Time to Live (TTL) ........................................................................................................... 5

3.9 Protocol ......................................................................................................................... 9

3.0 Header Checksum ....................................................................................................... 9

3. Source Address ........................................................................................................... 9

3.12DestinationAddress ..................................................................................................... 20

3.3 Options ........................................................................................................................ 20

3.3. General issues with IP options ................................................................................... 2

3.3.. Processing requirements ........................................................................................ 2

3.3..2 Processing of the options by the upper layer protocol ............................................ 22

3.3..3 General sanity checks on IP options ....................................................................... 22

3.13.2Issueswithspecicoptions ....................................................................................... 23

3.3.2. End of Option List (Type = 0) .................................................................................. 23

3.3.2.2 No Operation (Type = ) ......................................................................................... 24

3.3.2.3 Loose Source Record Route (LSRR) (Type = 3) .................................................. 24



2


3.3.2.4 Strict Source and Record Route (SSRR) (Type = 37) ............................................. 26

3.3.2.5 Record Route (Type = 7) ......................................................................................... 29

3.13.2.6StreamIdentier(Type=136) ................................................................................. 3

3.3.2.7 Internet Timestamp (Type = 68) .............................................................................. 3

3.3.2.8 Router Alert (Type = 48) ........................................................................................ 34

3.3.2.9 Probe MTU (Type =) ........................................................................................... 34

3.3.2.0 Reply MTU (Type = 2) ......................................................................................... 34

3.3.2. Traceroute (Type = 82) .......................................................................................... 35

3.13.2.12DoDBasicSecurityOption(Type=130)............................................................... 35

3.13.2.13DoDExtendedSecurityOption(Type=133)......................................................... 36

3.3.2.4 Commercial IP Security Option (CIPSO)................................................................ 36

3.13.2.15SenderDirectedMulti-DestinationDelivery(Type=149) ....................................... 37

3.14DifferentiatedServiceseld.......................................................................................... 37 3.15ExplicitCongestionNotication(ECN) ......................................................................... 38

4. Internet Protocol Mechanisms ............................................................................................. 40

4. Fragment reassembly .................................................................................................... 40

4.. Problems related with memory allocation .................................................................... 4

4.1.2ProblemsthatarisefromthelengthoftheIPIdenticationeld................................... 42

4.1.3Problemsthatarisefromthecomplexityofthereassemblyalgorithm ......................... 43

4..4 Problems that arise from the ambiguity of the reassembly process ............................. 434..5 Problems that arise from the size of the IP fragments ................................................. 44

4..6 Possible security improvements ................................................................................. 45

4.2 Forwarding .................................................................................................................... 49

4.2.1Precedence-orderedqueueservice............................................................................ 49

4.2.2 Weak Type of Service ................................................................................................. 50

4.2.3 Address Resolution .................................................................................................... 5

4.2.4Droppingpackets....................................................................................................... 5

4.3 Addressing .................................................................................................................... 52

4.3. Unreachable addresses .............................................................................................. 52

4.3.2 Private address space ................................................................................................ 52

4.3.3ClassDaddresses(224/4addressblock)................................................................... 52

4.3.4ClassEaddresses(240/4addressblock)................................................................... 52

4.3.5Broadcastandmulticastaddresses,andconnection-orientedprotocols .................... 53

4.3.6Broadcastandnetworkaddresses............................................................................. 53

4.3.7 Special Internet addresses ......................................................................................... 53

5. References ............................................................................................................................. 56



3


1. Preface

1.1 Introduction

TheTCP/IPprotocolswereconceivedduringatimethatwasquitedifferentfromthe

hostile environment they operate in now. Yet a direct result of their effectiveness and

widespread early adoption is that much of today’s global economy remains dependent

upon them.

WhilemanytextbooksandarticleshavecreatedthemyththattheInternetProtocols(IP)

weredesignedforwarfareenvironments,thetoplevelgoalfortheDARPAInternet

ProgramwasthesharingoflargeservicemachinesontheARPANET[Clark,1988].Asa

result,manyprotocolspecicationsfocusonlyontheoperationalaspectsoftheprotocols

they specify and overlook their security implications.

ThoughInternettechnologyhasevolved,thebuildingblocksarebasicallythesamecore

protocolsadoptedbytheARPANETmorethantwodecadesago.Duringthelasttwenty

yearsmanyvulnerabilitieshavebeenidentiedintheTCP/IPstacksofanumberof

systems.Somewereawsinprotocolimplementationswhichaffectonlyareduced

numberofsystems.Otherswereawsintheprotocolsthemselvesaffectingvirtuallyevery

existingimplementation[Bellovin,1989].Eveninthelastcoupleofyearsresearcherswere

stillworkingonsecurityproblemsinthecoreprotocols[Gont,2008][Watson,2004]

[NISCC,2004][NISCC,2005].

ThediscoveryofvulnerabilitiesintheTCP/IPprotocolsledtoreportsbeingpublishedbya

numberofCSIRTs(ComputerSecurityIncidentResponseTeams)andvendors,which

helped to raise awareness about the threats as well as the best mitigations known at the

time the reports were published.

Much of the effort of the security community on the Internet protocols did not result in

ofcialdocuments(RFCs)beingissuedbytheIETF(InternetEngineeringTaskForce)

leading to a situation in which “known” security problems have not always been

addressedbyallvendors.Inmanycasesvendorshaveimplementedquick“xes”to

protocolawswithoutacarefulanalysisoftheireffectivenessandtheirimpacton

interoperability[Silbersack,2005].

Asaresult,anysystembuiltinthefutureaccordingtotheofcialTCP/IPspecications

mightreincarnatesecurityawsthathavealreadyhitourcommunicationsystemsinthe

past.

ProducingasecureTCP/IPimplementationnowadaysisaverydifculttaskpartly

because of no single document that can serve as a security roadmap for the protocols.

ThereisclearlyaneedforacompaniondocumenttotheIETFspecicationsthat

discussesthesecurityaspectsandimplicationsoftheprotocols,identiesthepossible

threats,proposespossiblecounter-measures,andanalysestheirrespectiveeffectiveness.



4


ThisdocumentistheresultofanassessmentoftheIETFspecicationsoftheInternet

Protocolfromasecuritypointofview.Possiblethreatswereidentiedand,where

possible,counter-measureswereproposed.Additionally,manyimplementationawsthat

have led to security vulnerabilities have been referenced in the hope that future

implementations will not incur the same problems. This document does not limit itself toperformingasecurityassessmentoftherelevantIETFspecicationbutalsooffersan

assessment of common implementation strategies.

WhilstnotaimingtobethenalwordonthesecurityoftheIP,thisdocumentaimstoraise

awareness about the many security threats based on the IP protocol that have been faced

inthepast,thosethatwearecurrentlyfacing,andthosewemaystillhavetodealwithin

thefuture.ItprovidesadviceforthesecureimplementationoftheIP,andalsoinsights

about the security aspects of the IP that may be of help to the Internet operations

community.

Feedback from the community is more than encouraged to help this document be asaccurate as possible and to keep it updated as new threats are discovered.

1.2 Scope of this document

WhilethereareanumberofprotocolsthataffectthewayinwhichIPsystemsoperate,

thisdocumentfocusesonlyonthespecicationsoftheIP.Forexample,routingand

bootstrapping protocols are considered out of the scope of this project.

The following IETF RFCs were selected for assessment as part of this work:

• RFC791,“InternetProtocol.DARPAInternetProgram.ProtocolSpecication”(51

pages).

• RFC815,“IPdatagramreassemblyalgorithms”(9pages).

• RFC1122,“RequirementsforInternetHosts--CommunicationLayers”(116

pages).

• RFC1812,“RequirementsforIPVersion4Routers”(175pages).

• RFC2474,“DenitionoftheDifferentiatedServicesField(DSField)intheIPv4and

IPv6 Headers” (20 pages).

• RFC2475,“AnArchitectureforDifferentiatedServices”(36pages).

• RFC3168,“TheAdditionofExplicitCongestionNotication(ECN)toIP”(63pages).

1.3 Organisation of this document

Thisdocumentisbasicallyorganisedintwoparts:“InternetProtocolheaderelds”and

“InternetProtocolmechanisms”.Theformercontainsananalysisofeachoftheeldsof

theInternetProtocolheader,identiestheirsecurityimplications,anddiscussesthe

possiblecounter-measures.Thelattercontainsananalysisofthesecurityimplicationsof

the mechanisms implemented by the Internet Protocol.



5


1.4 Typographical conventions

ThroughoutthisdocumenttheheadereldsoftheInternetProtocolsarediscussedin

detail.Insomecases,agiventermmayhaveaslightlydifferentmeaningdependingon

whetheritisusedtorefertoaconceptortoaspeciceldoftheInternetProtocolheader.Toavoidanypossibleconfusionarisingfromthisambiguity,whenreferringtoa

speciceldoftheIPheaderthenameoftheeldiswritteninthisfont type.

Throughoutthedocumenttherearealsoanumberofparentheticalnotessuchasthisone,

toprovideadditionaldetailsorclarications.

1.5 Getting the latest version of this document

Itisexpectedthatrevisionsofthisdocumentwillbepublishedinresponsetothe

feedback provided by the community. Revisions of this document will be available at:

www.cpni.gov.uk/Products/technical.aspx

1.6 Advice and guidance to vendors

Vendors are urged to contact CPNI’s Vulteam ([email protected]) if they think they may

be affected by the issues described in this document. As the lead coordination center for

theseissues,CPNIiswellplacedtogiveadviceandguidanceasrequired.

CPNIworksextensivelywithgovernmentdepartmentsandagencies,commercial

organisations and the academic community to research vulnerabilities and potential

threatstoITsystems,especiallywheretheymayhaveanimpactonCriticalNationalInfrastructure’s (CNI).

OtherwaystocontactCPNI,plusCPNI’sPGPpublickey,areavailableat

www.cpni.gov.uk.

1.7 Acknowledgements

This assessment was written by Fernando Gont on behalf of CPNI.

TheauthorwouldliketothankRandallAtkinson,JohnDay,JuanFraschini,RoqueGagliano,GuillermoGont,MartinMarino,PekkaSavola,andChristosZoulasforproviding

valuable comments on earlier versions of this document.

TheauthorwouldliketothankRandallAtkinsonandRoqueGagliano,whogenerously

answered a number of questions.

Finally,theauthorwouldliketothankCPNIfortheircontinuedsupport.



6


2. The Internet Protocol

TheIPprovidesabasicdatatransferfunction,intheformofdatablockscalled

“datagrams”,fromasourcehosttoadestinationhost,acrossthepossibleintervening

networks. It additionally provides some functions that are useful for the interconnection of

heterogeneousnetworks,suchasfragmentationandreassembly.

The “datagram” has a number of characteristics that makes it convenient for

interconnectingsystems[Clark,1988]:

• Iteliminatestheneedofconnectionstatewithinthenetwork,whichimprovesthe

survivability characteristics of the network.

• It provides a basic service of data transport that can be used as a building block for

othertransportservices(reliabledatatransportservices,etc.).

• Itrepresentstheminimumnetworkserviceassumption,whichenablesIPtoberun

over virtually any network technology.



7


3. Internet Protocol header elds

TheIETFspecicationsoftheInternetProtocoldenethesyntaxoftheprotocolheader,

alongwiththesemanticsofeachofitselds.Figure1showstheformatofanIP

datagram.

Figure : Internet Protocol header format

EvenwhentheminimumIPheadersizeis20bytes,anIPmodulemightbehandedan

(illegitimate)“datagram”oflessthan20bytes.Therefore,beforedoinganyprocessingof

theIPheaderelds,thefollowingcheckshouldbeperformedbytheIPmoduleonthepacketshandedbythelink-layer:

link-layer.PayloadSize>=20

If the packet does not pass this check it should be dropped.

The following subsections contain further sanity checks that should be performed on IP

packets.

3.1 Version

Thisisa4-biteldthatindicatestheversionoftheIP,andthusthesyntaxofthepacket.

ForIPv4,thiseldmustbe4.

Whenalink-layerprotocolde-multiplexesapackettoaninternetmodule,itdoesso

basedona“ProtocolType”eldinthedata-linkpacketheader.

Intheory,differentversionsofIPcouldcoexistonanetworkbyusingthesame“Protocol

Type”atthelink-layer,butadifferentvalueintheVersioneldoftheIPheader.Thusa

singleIPmodulecouldhandleallversionsoftheInternetProtocol,differentiatingthemby

meansofthiseld.



8


However,inpracticedifferentversionsofIPareidentiedbyadifferent“ProtocolType”

numberinthelink-layerprotocolheader.Forexample,IPv4datagramsareencapsulated

inEthernetframesusinga“ProtocolType”eldof0x0800,whileIPv6datagramsare

encapsulatedinEthernetframesusinga“ProtocolType”eldof0x86DD[IANA,2006a].

ThereforeifanIPv4modulereceivesapacket,the Versioneldmustbecheckedtobe4.

If this check fails the packet should be silently dropped.

3.2 IHL (Internet Header Length)

TheIHL(InternetHeaderLength)indicatesthelengthoftheinternetheaderin32-bit

words(4bytes).Astheminimumdatagramsizeis20bytes,theminimumlegalvaluefor

thiseldis5andthefollowingcheckshouldbeenforced:

IHL>=5

Forobviousreasons,theInternetheadercannotbelargerthanthewholeInternet

datagram it is part of and therefore the following check should be enforced:

IHL * 4 <= Total Length

TheabovecheckallowsforInternetdatagramswithnodatabytesinthepayloadthat,

whilenonsensicalforvirtuallyeveryprotocolthatrunsoverIP,isstilllegal.

3.3 TOS

Figure2showsthesyntaxoftheType of Service eld,denedbyRFC791[Postel,

1981],andupdatedbyRFC1349[Almquist,1992].

Figure2:TypeofServiceeld

Bits 0-2: Precedence.

Bit 3: 0=NormalDelay,1=LowDelay.

Bits 4: 0=NormalThroughput,1=HighThroughput.

Bit 5: 0=NormalReliability,1=HighReliability.

Bit 6: 0=NormalCost,1=MinimiseMonetaryCost

Bits 7: ReservedforFutureUse(mustbezero).



9


Where:

Precedence

: Network Control

0: Internetwork 101: CRITIC/ECP

00: Flash Override

0: Flash

00: Immediate

00: Priority

000: Routine

The Type of Serviceeldcanbeusedtoaffectthewayinwhichthepacketistreatedby

thesystemsofanetworkthatprocessit.Section4.2.1(“Precedence-orderedqueue

service”) and Section 4.2.3 (“Weak TOS”) of this document describe the securityimplications of the Type of Serviceeldintheforwardingofpackets.

3.4 Total Length

The Total Lengtheldisthelengthofthedatagram,measuredinbytes,includingboth

theIPheaderandtheIPpayload.Beinga16-biteld,itallowsfordatagramsofupto

65535bytes.RFC791[Postel,1981]statesthatallhostsshouldbepreparedtoreceive

datagramsofupto576bytes(whethertheyarriveasawholeorinfragments).However,

most modern implementations can reassemble datagrams of at least 9 Kbytes.

Usually a host will not send to a remote peer an IP datagram larger than 576 bytes unless

itisexplicitlysignaledthattheremotepeerisabletoreceivesuch“large”datagrams(for

example,bymeansofTCP’sMSSoption).However,systemsshouldassumethatthey

may be sent datagrams larger than 576 bytes regardless of whether they signal their

remotepeerstodosoornot.InfactitiscommonforNFS[Shepleretal,2003]

implementationstosenddatagramslargerthan576bytes,evenwithoutexplicitsignaling

that the destination system can receive such “large” datagram.

Additionally,seethediscussioninSection4.1“Fragmentreassembly”regardingthepossible

packet sizes resulting from fragment reassembly.

Implementations should be aware that the IP module could be handed a packet larger

thanthevalueactuallycontainedintheTotalLengtheld.Suchadifferenceusuallyhasto

dowithlegitimatepaddingbytesatthelink-layerprotocol,butitcouldalsobetheresultof

maliciousactivitybyanattacker.Furthermore,evenwhenthemaximumlengthofanIP

datagramis65535bytes,ifthelink-layertechnologyinuseallowsforpayloadslargerthan

65535bytesanattackercouldforgesuchalargelink-layerpacket,meaningitfortheIP

module. If the IP module of the receiving system were not prepared to handle such an

oversizedlink-layerpayloadanunexpectedfailuremightoccur.Therefore,thememory

bufferusedbytheIPmoduletostorethelink-layerpayloadshouldbeallocatedaccording

tothepayloadsizereportedbythelink-layer,ratherthanaccordingtotheTotalLength

eldoftheIPpacketitcontains.



0


The IP module could also be handled a packet that is smaller than the actual IP packet

size claimed by the Total Lengtheld.Thiscouldbeused,forexample,toproducean

information leakage. Therefore the following check should be performed:

Link-layer.PayloadSize>=Total Length

IfthischeckfailstheIPpacketshouldbedropped.Asthepreviousexpressionimplies,

thenumberofbytespassedbythelink-layertotheIPmoduleshouldcontainatleastas

many bytes as claimed by the Total LengtheldoftheIPheader.

[US-CERT,2002]isanexampleoftheexploitationofaforgedIPTotal Lengtheldto

produce an information leakage attack.

3.5 Identication (ID)

The Identicationeldissetbythesendinghosttoaidinthereassemblyoffragmented

datagrams.Atanytime,itneedstobeuniqueforeachsetof{Source Address,

Destination Address, Protocol}.

InmanysystemsthevalueusedforthiseldisdeterminedattheIPlayeronaprotocol-

independent basis. Many of those systems also simply increment the IP Identication

eldforeachpackettheysend.

Thisimplementationstrategyisinappropriateforanumberofreasons.First,ifthe

Identicationeldissetonaprotocol-independentbasis,itwillwrapmoreoftenthan

necessary,andthustheimplementationwillbemorepronetotheproblemsdiscussedin[KentandMogul,1987]and[Heffner,Mathis,andChandler,2006].

Secondly,thisimplementationstrategyopensthedoortoaninformationleakagethatcan

beexploitedtoinanumberofways.[Sanlippo,1998a]originallypointedouthowthis

eldcouldbeexaminedtodeterminethepacketrateatwhichagivensystemis

transmittinginformation.Later,[Sanlippo,1998b]describedhowasystemwithsuchan

implementation can be used to perform a stealth port scan to a third (victim) host.

[Sanlippo,1999]explainedhowtoexploitthisimplementationstrategytouncoverthe

rulesofanumberofrewalls.[Bellovin,2002]explainshowtheIPIdenticationeldcan

beexploitedtocountthenumberofsystemsbehindaNAT.[Fyodor,2004]isanentire

paperonmost(ifnotall)thewaystoexploittheinformationprovidedbytheIdenticationeldoftheIPheader.

3.5.1 Some workarounds implemented by the industry

As the IP Identicationeldisonlyusedforthereassemblyofdatagrams,

someoperatingsystems(suchasLinux)decidedtosetthiseldto0inall

packetsthathavetheDFbitset.Thiswould,inprinciple,avoidanytypeof

informationleakage.However,itwasdetectedthatsomenon-RFC-compliant

middle-boxesfragmentedpacketseveniftheyhadtheDFbitset.Insucha

scenarioalldatagramsoriginallysentwiththeDFbitsetwouldresultin

fragments that would have an Identicationeldof0,whichwouldleadto

problems(“collision”oftheIdenticationnumber)inthereassemblyprocess.




Linux(andSolaris)latersettheIPIdenticationeldonaper-IP-address

basis. This avoids some of the security implications of the IP Identication

eld,butnotall.Forexample,systemsbehindaloadbalancercanstillbe

counted.

3.5.2 Possible security improvements

Contrarytocommonwisdom,theIP Identicationelddoesnotneedtobe

system-wideuniqueforeachpacket,buthastobeuniqueforeach{Source

Address, Destination Address, Protocol} tuple.

Forinstance,theTCPspecicationdenesagenericsend()functionwhich

takestheIPIDasoneofitsarguments.

We provide an analysis of the possible security improvements that could be

implemented,basedonwhethertheprotocolusingtheservicesofIPisconnection-orientedorconnection-less.

Connection-oriented protocols

Toavoidthesecurityimplicationsoftheinformationleakagedescribedabove,

apseudo-randomnumbergenerator(PRNG)couldbeusedtosettheIP

Identicationeldona{Source Address, Destination Address} basis (for

eachconnection-orientedtransportprotocol).

[Klein,2007]isasecurityadvisorythatdescribesaweaknessinthepseudo

random number generator (PRNG) in use for the generation of the IPIdentication by a number of operating systems.

Whileintheoryapseudo-randomnumbergeneratorcouldleadtoscenarios

in which a given Identication number is used more than once in the same

time-spanfordatagramsthatendupgettingfragmented(withthe

correspondingpotentialreassemblyproblems),inpracticethisisunlikelyto

cause trouble.

Bydefault,mostimplementationsofconnection-orientedprotocols,suchas

TCP,implementsomemechanismforavoidingfragmentation(suchasthe

Path-MTUDiscoverymechanism[MogulandDeering,1990]).Thus,

fragmentationwillonlytakeplacesporadicallywhenanon-RFC-compliant

middle-boxisplacedsomewherealongthepaththatthepacketstraveltoget

tothedestinationhost.Oncethesendingsystemissignaledbythemiddle-

boxthatitshouldreducethesizeofthepacketsitsends,fragmentation

wouldbeavoided.Also,forreassemblyproblemstoarise,thesame

Identicationeldshouldbefrequentlyreusedandeitherstrongpacket

reordering or packet loss should take place.

Nevertheless,regardlessofwhatpolicyisusedforselectingthe

Identicationeld,withthecurrentlinkspeedsfragmentationisalreadybad



2


enough to rely on it. A mechanism for avoiding fragmentation should be

implemented instead.

Connectionless protocols

Connectionless protocols usually have these characteristics:

• lackofow-controlmechanisms,

• lack of packet sequencing mechanisms

• lack of reliability mechanisms (such as “timeout and retransmit”).

Thismeansthatthescenariosand/orapplicationsforwhichconnection-less

transport protocols are used assume that:

• Applications will be used in environments in which packet reordering is

veryunlikely(suchasLocalAreaNetworks),asthetransportprotocol

itself does not provide data sequencing.

• Thedatatransferrateswillbelowenoughthatowcontrolwillbe

unnecessary.

• Packet loss is not important and probably also unlikely.

Withtheseassumptionsinmind,theIdenticationeldcouldstillbeset

accordingtoapseudo-randomnumbergenerator(PRNG).Intheeventa

given Identicationnumberwasreusedwhiletherstinstanceofthesame

numberisstillonthenetwork,therstIPdatagramwouldbereassembled

before the fragments of the second IP datagram get to their destination.

Intheeventthiswasnotthecase,thereassemblyoffragmentswouldresult

inacorruptdatagram.Whilesomeexistingwork[Silbersack,2005]assumes

thatthiserrorwouldbecaughtbysomeupper-layererrordetectioncode,the

errordetectioncodeinquestion(suchasUDP’schecksum)mightbeintended

todetectsinglebiterrors,ratherthandatacorruptionarisingfromthe

replacement of a complete data block (as is the case in corruption arising

from collision of IP Identication numbers).

InthecaseofUDP,unfortunatelysomesystemshavebeenknowntonot

enabletheUDPchecksumbydefault.Formostapplications,packetscontaining errors should be dropped. Probably the only application that maybenetfromdisablingthechecksumisstreamingmedia,toavoiddroppinga

completesampleforasingle-biterror.

Ingeneral,ifIPIdentication number collisions become an issue for the

applicationusingtheconnection-lessprotocol,thenuseofadifferent

transport protocol (which hopefully avoids fragmentation) should be

considered.

AnattackercouldintentionallyexploitcollisionsofIPIdentication numbers

toperformaDenialofServiceattackbysendingforgedfragmentsthatwouldcausethereassemblyprocesstoresultinacorruptdatagram,thatwould



3


either be dropped by the transport protocol or would incorrectly be handed to

the corresponding application. This issue is discussed in detail in section 4.

(“Fragment Reassembly”).

3.6 Flags

TheIPheadercontains3controlbits,twoofwhicharecurrentlyusedforthe

fragmentation and reassembly function.

AsdescribedbyRFC791,theirmeaningis:

Bit0: reserved,mustbezero

Bit1: (DF)0=MayFragment,1=Don’tFragment

Bit2: (MF)0=LastFragment,1=MoreFragments

The DFbitisusuallysettoimplementthePath-MTUDiscovery(PMTUD)mechanism

describedin[MogulandDeering,1990].However,itcanalsobeexploitedbyanattacker

toevadeNetworkIntrusionDetectionSystems.Anattackercouldsendapacketwiththe

DFbitsettoasystemmonitoredbyaNIDS,anddependingonthePath-MTUtothe

intendedrecipient,thepacketmightbedroppedbysomeinterveningrouter(beingtoobig

tobeforwardedwithoutfragmentation),withouttheNIDSbeingaware.

Figure3:NIDSevasionbymeansoftheInternetProtocolDFbit



5


datagramsofupto65535bytes.Therefore,ifagivenfragmentwouldreassembleintoa

datagramofmorethan65535bytes,theresultingdatagramshouldbedropped.To

detectsuchacase,thefollowingcheckshouldbeenforcedonallpacketsforwhichthe

Fragment Offsetcontainsanon-zerovalue:

Fragment Offset * 8 + (Total Length – IHL * 4) <= 65535

Intheworst-casescenario,thereassembleddatagramcouldhaveasizeofupto131043

bytes.

SuchadatagramwouldresultwhentherstfragmenthasaFragment Offset of 0 and a

Total Lengthof65532,andthesecond(andlast)fragmenthasaFragment Offset of 8189(65512bytes),andaTotal Length of 65535. Assuming an IHLof5(i.e.,aheader

lengthof20bytes),thereassembleddatagramwouldbe65532+(65535–20)=131047

bytes.

The IP module should implement all the necessary measures to be able to handle such

illegitimatereassembleddatagrams,soastoavoidthemfromoverowingthebuffer(s)

used for the reassembly function.

[CERT,1996c]and[Kenney,1996]describetheexploitationofthisissuetoperformaDenial

ofService(DoS)attack.

3.8 Time to Live (TTL)

The Time to Live (TTL)eldhastwofunctions:tobindthelifetimeoftheupper-layer

packets(e.g.TCPsegments)andtopreventpacketsfromloopingindenitelyinthenetwork.

Originally,thiseldwasmeanttoindicatemaximumtimeadatagramwasallowedto

remain within the internet system in units of seconds. As every internet module that

processes a datagram must decrement the TTLbyatleastone,theoriginaldenitionof

the TTLeldbecameobsolete,anditmustnowbeinterpretedasahopcount.

MostsystemsallowtheadministratortoconguretheTTLtobeusedforthepacketssent

with the default value usually being a power of 2. The recommended value for the TTL

eld,asspeciedbytheIANAis64[IANA,2006b].Thisvaluereectstheassumed“diameter” of the Internet plus a margin to accommodate its growth.

The TTLeldhasanumberofpropertiesthatareinterestingfromasecuritypointofview.

Given that the default value used for the TTL is usually a power of eight the chances are

that,unlesstheoriginatingsystemhasbeenexplicitlytunedtouseanon-defaultvalue,if

a packet arrives with a TTL of 60 the packet was originally sent with a TTL of 64. In the

same way if a packet is received with a TTL of 20 chances are that the original packet

had a TTL of 28.

Thisdiscussionassumestherewasnoprotocolscrubber,transparentproxy,orsomeother

middle-boxthatoverwritestheTTLeldinanon-standardway,betweentheoriginatingsystem and the point of the network in which the packet was received.



6


Asserting the TTL with which a packet was originally sent by the source system can help

toobtainvaluableinformation.Amongotherthings,itmayhelpin:

• Fingerprinting the operating system being used by the source host.

• Fingerprinting the physical device from which the packets originate.• Locating the source host in the network topology.

Additionally,itcanbeusedtoperformfunctionssuchas:

• EvadingNetworkIntrusionDetectionSystems.

• Improving the security of applications that make use of the IP.

Fingerprinting the operating system in use by the source host

DifferentoperatingsystemsuseadifferentdefaultTTL for the packets they send so

asserting the TTL with which a packet was originally sent will help to reduce the number

of possible operating systems in use by the source host.

Fingerprinting the physical device from which the packets originate

Whenseveralsystemsarebehindamiddle-boxsuchasaNAToraloadbalancer,the

TTLmayhelptocountthenumberofsystemsbehindthemiddle-box.Ifeachofthe

systemsbehindthemiddle-boxuseadifferentdefaultTTLforthepacketstheysend,or

theyarelocatedinadifferentplaceofthenetworktopology,anattackercouldstimulate

responsesfromthedevicesbeingngerprintedandeachresponsethatarriveswitha

different TTL could be assumed to come from a different device.

Ofcourse,thereareothermoreprecisetechniquestongerprintphysicaldevices.Amongst

thedrawbacksofthismethod,whilemanysystemsdifferinthedefaultTTL they use for thepacketstheysend,therearealsomanyimplementationswhichusethesamedefaultTTL. Additionally,packetssentbyagivendevicemaytakedifferentroutes(e.g.duetoload

sharing or route changes) and thus a given packet may incorrectly be presumed to comefrom a different device when in fact it just traveled a different route.

Locating the source host in the network topology

The TTLeldmayalsobeusedtolocatethesourcesysteminthenetworktopology

[NorthcuttandNovak,2000].



7


Figure4:TrackingahostbymeansoftheTTLeld

ConsidernetworktopologyofFigure4.Assumingthatanattacker(“F”inthegure)is

performing an attack that requires forging the Source Address(suchasaTCP-based

DoSreectionattack),andsomeoftheinvolvedhostsarewillingtocooperatetolocate

the attacking system.

Assuming that:

• All the packets A gets have a TTL of 6. • AllthepacketsBgetshaveaTTL of 6.

• All the packets C gets have a TTL of 6.

• AllthepacketsDgetshaveaTTL of 62.

Basedonthisinformation,andassumingthatthesystem’sdefaultvaluewasnot

overridden,itwouldbefairtoassumethattheoriginalTTL of the packets was 64. With

this information the number of hops between the attacker and each of the aforementioned

hosts can be calculated.

The attacker is:

• Three hops away from A.

• ThreehopsawayfromB.

• Three hops away from C.

• TwohopsawayfromD.

InthenetworksetupofFigure3,theonlysystemthatsatisesalltheseconditionsisthe

one marked as the “F”.

Thescenariodescribedaboveisforillustrationpurposesonly.Inpractice,therearea

number of factors that may prevent this technique from being successfully applied:



8


• Unlessthereisa“large”numberofcooperatingsystems,andtheattackeris

assumedtobenomorethanafewhopsawayfromthesesystems,thenumberof

“candidate” hosts will usually be too large for the information to be useful.

• Theattackermaybeusinganon-defaultTTLvalueor,worse,usingapseudo-random value for the TTL of the packets it sends.

• Thepacketssentbytheattackermaytakedifferentroutes,asaresultofachange

innetworktopology,loadsharing,etc.,andmayleadtoanincorrectanalysis.

Evading Network Intrusion Detection Systems

The TTLeldcanbeusedtoevadeNetworkIntrusionDetectionSystems.Dependingon

thepositionofasensorrelativetothedestinationhostoftheexaminedpacket,theNIDS

maygetadifferentpicturefromthatoftheintendeddestinationsystem.Asanexample,a

sensormayprocessapacketthatwillexpirebeforegettingtothedestinationhost.A

generalcounter-measureforthistypeofattackistonormalisethetrafcthatgetstoan

organisationalnetwork.Examplesofsuchtrafcnormalisationcanbefoundin[Paxsonet

al,2001].

Improving the security of applications that make use of the Internet

Protocol (IP)

In some scenarios the TTLeldcanbealsousedtoimprovethesecurityofanapplication

byrestrictingthehoststhatcancommunicatewiththegivenapplication.Forexample,

there are applications for which the communicating systems are typically in the samenetworksegment(i.e.,therearenointerveningrouters).SuchanapplicationistheBGP

(BorderGatewayProtocol)betweenutilisedbytwopeerrouters.

If both systems use a TTLof255forallthepacketstheysendtoeachother,thena

check could be enforced to require all packets meant for the application in question to

have a TTL of 255.

As all packets sent by systems that are not in the same network segment will have a TTL

smallerthan255,thosepacketswillnotpassthecheckenforcedbythesetwo

cooperating peers. This check reduces the set of systems that may perform attacks

againsttheprotectedapplication(BGPinthiscase),thusmitigatingtheattackvectors

describedin[NISCC,2004]and[Watson,2004].

ThissamecheckisenforcedforrelatedICMPerrormessages,withtheintentofmitigating

theattackvectorsdescribedin[NISCC,2005]and[Gont,2008].

.

The TTLeldcansimilarlybeusedinscenariosinwhichthecooperatingsystemseither

do not use a default TTLof255,orarenotinthesamenetworksegment(i.e.,multi-hop

peering).Inthatcase,thefollowingcheckcouldbeenforced:

TTL>=255-Δhops



9


This means that the set of hosts from which packets will be accepted for the protected

applicationwillbereducedtothosethatarenomorethanΔhopsaway.Whileforobvious

reasonsthelevelofprotectionwillbesmallerthaninthecaseofdirectly-connectedpeers,

the use of the TTLeldforprotectingmulti-hoppeeringstillreducesthesetofhoststhat

could potentially perform a number of attacks against the protected application.

This use of the TTLeldhasbeenofciallydocumentedbytheIETFunderthename

“GeneralisedTTLSecurityMechanism”(GTSM)in[Gilletal,2007].

Some protocol scrubbers enforce a minimum value for the TTLeldofthepacketsthey

forward. It must be understood that depending on the minimum TTLbeingenforced,and

dependingontheparticularnetworksetup,theprotocolscrubbermayactuallyhelp

attackerstofooltheGTSM,by“raising”theTTL of the attacking packets.

3.9 Protocol

The Protocoleldindicatestheprotocolencapsulatedintheinternetdatagram.The

Protocoleldmaynotonlycontainavaluecorrespondingtoanimplementedprotocol

within the system but also a value corresponding to a protocol not implemented or even a

valuenotyetassignedbytheIANA[IANA,2006c].

While in theory there should not be security implications from the use of any value in the

protocoleld,therehavebeensecurityissuesinthepastwithsystemsthathadproblems

whenhandlingpacketswithsomespecicprotocolnumbers[Cisco,2003][CERT,2003].

3.10 Header Checksum

The Header Checksumeldisanerrordetectionmechanismmeanttodetecterrorsin

the IP header. While in principle there should not be security implications arising from this

eld,itshouldbenotedthatduetonon-RFC-compliantimplementations,theHeader

Checksummightbeexploitedtodetectrewallsand/orevadenetworkintrusion

detectionsystems(NIDS).

[Ed3f,2002]describestheexploitationoftheTCPchecksumforperformingsuchactions.

As there are internet routers known to not check the IP Header Checksum,andthere

mightalsobemiddle-boxes(NATs,rewalls,etc.)notcheckingtheIPchecksumallegedly

duetoperformancereasons,similarmaliciousactivitytotheonedescribedin[Ed3f,2002]

might be performed with the IP checksum.

3.11 Source Address

The Source AddressofanIPdatagramidentiesthenodefromwhichthepacket

originated.

Strictlyspeaking,theSource AddressofanIPdatagramidentiestheinterfaceofthe

sendingsystemfromwhichthepacketwassent,(ratherthantheoriginating“system”),asin

the Internet Architecture there’s no concept of “node”.



20


Unfortunately it is trivial to forge the Source Address of an Internet datagram. This has

beenexploitedinthepastforperformingavarietyofDoS(DenialofService)attacks(see

[NISCC,2004][Eddy,2007][CERT,1996a][CERT,1996b][CERT,1998a])andto

impersonate as other systems in scenarios in which authentication was based on the

Source Addressofthesendingsystem[daemon9etal,1996].

TheextenttowhichtheseattackscanbesuccessfullyperformedintheInternetcanbe

reducedthroughdeploymentofingress/egresslteringintheinternetrouters.[NISCC,

2006]isadetailedguideoningressandegressltering.[BakerandSavola,2004]and

[FergusonandSenie,2000]discussingressltering.[GIAC,2000]discussesegress

ltering.

Evenwhentheobviouseldonwhichtoperformchecksforingress/egresslteringisthe

Source Address and Destination AddresseldsoftheIPheader,thereareother

occurrences of IP addresses on which the same type of checks should be performed. One

exampleistheIPaddressescontainedinthepayloadofICMPerrormessages,asdiscussedin[Gont,2008]and[Gont,2006].

There are a number of sanity checks that should be performed on the Source Address

ofanIPdatagram.DetailscanbefoundinSection4.2(“Addressing”).

Additionally,therearefreelyavailabletoolsthatallowadministratorstomonitorwhichIP

addressesareusedwithwhichMACaddresses[LBNL/NRG,2006].Thisfunctionalityis

alsoincludedinmanyNetworkIntrusionDetectionSystems(NIDS).

It is also very important to understand that authentication should never rely on the Source

Address of the communicating systems.

3.12 Destination Address

The Destination AddressofanIPdatagramidentiesthedestinationhosttowhichthe

packet is meant to be delivered.

Strictlyspeaking,theDestination AddressofanIPdatagramidentiestheinterfaceof

thedestinationnetworkinterface,ratherthanthedestination“system”.AsintheInternet

Architecture there is no concept of “node”.

There are a number of sanity checks that should be performed on the Destination

AddressofanIPdatagram.DetailscanbefoundinSection4.2(“Addressing”).

3.13 Options

AccordingtoRFC791,IPoptionsmustbeimplementedbyallIPmodules,bothinhosts

andgateways(i.e.,end-systemsandintermediate-systems).

There are two cases for the format of an option:

• Case : A single byte of option-type.• Case 2: An option-typebyte,anoption-lengthbyte,andtheactualoption-data

bytes.



2


InCase2,theoption-length byte counts the option-type byte and the option-length

byte,aswellastheactualoption-databytes.

Alloptions,except“EndofOptionList”(Type=0)and“NoOperation”(Type=1),areof

Class 2.

The option-typehasthreeelds:

• bit: copied ag.

• 2 bits: option class.

• 5 bits: option number.

The copied ag indicates whether this option should be copied to all fragments when the

packet carrying it needs to be fragmented:

• 0 = not copied.

• = copied.

The values for the option class are:

• 0 = control.

• = reserved for future use.

• 2 = debugging and measurement.

• 3 = reserved for future use.

ThisformatallowsforthecreationofnewoptionsfortheextensionoftheIP.

Finally,theoption numberidentiesthesyntaxoftherestoftheoption.

3.13.1 General issues with IP options

The following subsections discuss security issues that apply to all IP options.

Theproposedchecksshouldbeperformedinadditiontoanyoption-specic

checksproposedinthenextsections.

3.13.1.1 Processing requirements

Router manufacturers tend to do IP option processing on the main processor

rather than on line cards. Unless special care is taken this may be a security

risk as there is potential for overwhelming the router with option processing.

Toreducetheimpactofthesepacketsonthesystemperformance,afew

counter-measurescouldbeimplemented:

• Rate-limitthenumberofpacketswithIPoptionsthatareprocessedby

the system.

• Enforcealimitonthemaximumnumberofoptionstobeacceptedonagiven internet datagram.



22


TherstcheckavoidsaowofpacketswithIPoptionstooverwhelmthe

system in question. The second check avoids packets with multiple IP options

to affect the performance of the system.

3.13.1.2 Processing of the options by the upper layer protocol

Section3.2.1.8ofRFC1122[Braden,1989]statesthatalltheIPoptions

received in IP datagrams must be passed to the transport layer (or to ICMP

processing when the datagram is an ICMP message). Care in option

processing must be taken not only at the internet layer but also in every

protocol module that may end up processing the options included in an IP

datagram.

3.13.1.3 General sanity checks on IP options

There are a number of sanity checks that should be performed on IP options

before further option processing is done. They help prevent a number of

potentialsecurityproblemsincludingbufferoverows.Whenthesechecksfail

the packet carrying the option should be dropped.

RFC1122[Braden,1989]recommendstosendanICMP“Parameter

Problem” message to the originating system when a packet is dropped

becauseofainvalidvalueinaeld,suchasthecasesdiscussedinthe

following subsections. Sending such a message might help in debugging

some network problems. However it would also alert attackers about the

system that is dropping packets because of the invalid values in the protocolelds.

We advise that systems default to sending an ICMP “Parameter Problem”

error message when a packet is dropped because of an invalid value in a

protocoleld(e.g.asaresultofdroppingapacketduetothesanitychecks

described in this section). However we recommend that systems provide a

system-widetogglethatallowsanadministratortooverridethedefault

behavior so that packets can be silently dropped when an invalid value in a

protocoleldisencountered.

Option length

Section3.2.1.8ofRFC1122explicitlystatesthattheIPlayermustnotcrash

astheresultofanoptionlengththatisoutsidethepossiblerange,and

mentions that erroneous option lengths have been observed to put some IP

implementationsintoinniteloops.

Foroptionsthatbelongtothe“Case2”describedintheprevioussection,the

following check should be performed:



23


option-length>=2

The value “2” accounts for the option-typebyte,andtheoption-length byte.

Thischeckprevents,amongotherthings,loopsinoptionprocessingthatmay

arise from incorrect option lengths.

Additionally,whiletheoption-length byte of IP options of “Case 2” allows for

anoptionlengthofupto255bytes,thereisalimitonlegitimateoptionlength

imposedbythesyntaxoftheIPheader.

Foralloptionsof“Case2”,thefollowingcheckshouldbeenforced:

option-offset+option-length <= IHL * 4

Whereoption-offsetistheoffsetoftherstbyteoftheoptionwithintheIP

header,withtherstbyteoftheIPheaderbeingassignedanoffsetof0.

Ifapacketdoesnotpassbothofthesechecks,itshouldbedropped.

The aforementioned check is meant to detect forged option-length values

that might make an option overlap with the IP payload. This would be

particularly dangerous for those IP options which request the processing

systemstowriteinformationintotheoption-dataarea(suchastheRecord

Routeoption),asitwouldallowthegenerationofoverows.

Data types

ManyIPoptionsusepointerandlengthelds.Caremustbetakenastothe

datatypeusedfortheseeldsintheimplementation.Forexample,ifan8-bit

signeddatatypewereusedtoholdan8-bitpointer,thenpointervalueslarger

than 28 might mistakenly be interpreted as negative numbers and might lead

to unpredictable results.

3.13.2 Issues with specic options

3.13.2.1 End of Option List (Type = 0)

This option is used to indicate the “end of options” in those cases in which

the end of options would not coincide with the end of the Internet Protocol

Header.

IP systems are required to ignore those options they do not implement.

Therefore,eveninthosecasesinwhichthisoptionisrequired,butismissing,

IP systems should be able to process the remaining bytes of the IP header

without any problems.



24


3.13.2.2 No Operation (Type = 1)

Theno-operationoptionisbasicallymeanttoallowthesendingsystemto

alignsubsequentoptionsin,forexample,32-bitboundaries.

This option does not have security implications.

3.13.2.3 Loose Source Record Route (LSRR) (Type = 131)

This option lets the originating system specify a number of intermediate

systems a packet must pass through to get to the destination host.

Additionally,theroutefollowedbythepacketisrecordedintheoption.The

receivinghost(end-system)mustusethereverseofthepathcontainedinthe

received LSRR option.

The LSSR option can be of help in debugging some network problems. Some

ISP Internet Service Provider) peering agreements require support for this

option in the routers within the peer of the ISP.

TheLSRRoptionhaswell-knownsecurityimplications.Amongotherthings,

the option can be used to:

• Bypassrewallrules

• Reach otherwise unreachable internet systems

• Establish TCP connections in a stealthy way

• Learn about the topology of a network • Performbandwidth-exhaustionattacks

Oftheseattackvectors,theonethathasprobablyreceivedleastattentionis

theuseoftheLSRRoptiontoperformbandwidthexhaustionattacks.The

LSRRoptioncanbeusedasanamplicationmethodforbandwidth-

exhaustionattacksasanattackercouldmakeapacketbouncemultipletimes

between a number of systems by carefully crafting an LSRR option.

ThisistheIPv4-versionoftheIPv6amplicationattackthatwaswidely

publicisedin2007[BiondiandEbalard,2007].Theonlydifferenceisthatthe

maximumlengthoftheIPv4header(andhencetheLSRRoption)limitstheamplicationfactorwhencomparedtotheIPv6counter-part.

WhiletheLSSRoptionmaybeofhelpindebuggingsomenetworkproblems,

its security implications outweigh any legitimate use.

Allsystemsshould,bydefault,dropIPpacketsthatcontainanLSRRoption.

However,theyshouldprovideasystem-widetoggletoenablesupportforthis

optionforthosescenarioswhereoptionisrequired.Suchasystem-wide

toggle should default to “off” (or “disable”).



25


[OpenBSD,1998]isasecurityadvisoryaboutanimproperimplementationof

suchasystem-widetogglein4.4BSDkernels.

Section3.3.5ofRFC1122[Braden,1989]statesthatahostmaybeableto

actasanintermediatehopinasourceroute,forwardingasource-routeddatagramtothenextspeciedhop.Westronglydiscouragehostsoftware

fromforwardingsource-routeddatagrams.

Ifprocessingofsource-routeddatagramsisexplicitlyenabledinasystem,the

following sanity checks should be performed.

RFC791statesthatthisoptionshouldappear,atmost,onceinagiven

packet.If a packet is found to have more than one LSRR option it should be

dropped.Therefore,hostsandroutersshoulddiscardpacketsthatcontain

morethanoneLSRRoption.Additionally,ifapacketwerefoundtohaveboth

LSRR and SSRR options it should be dropped.

AsmanyotherIPoptionstheLSSRcontainsaLengtheldthatindicatesthe

lengthoftheoption.GiventheformatoftheoptiontheLengtheldshouldbe

checked to be at least 3 (three):

LSRR.Length>=3


Additionally,thefollowingcheckshouldbeperformedontheLengtheld:

LSRR.Offset + LSRR.Length < IHL *4

ThischeckassuresthattheoptiondoesnotoverlapwiththeIPpayload(i.e.,

it does not go past the IP header). If the packet does not pass this check it

should be dropped.

The Pointerisrelativetothisoption.Thus,theminimumlegalvalueis4.

Therefore,thefollowingcheckshouldbeperformed.

LSRR.Pointer>=4

Ifthepacketdoesnotpassthischeckitshouldbedropped.Additionally,the

Pointereldshouldbeamultipleof4.Consequently,thefollowingcheck

should be performed:

LSRR.Pointer % 4 == 0

If a packet does not pass this check it should be dropped.

WhenasystemreceivesanIPpacketwiththeLSRRrouteoption,itshould

check whether the source route is empty or not. The option is empty if:



26


LSRR.Pointer >LSRR.Length

In that case routing should be based on the Destination Addresseldand

no further processing should be done on the LSRR option.

[Microsoft,1999]isasecurityadvisoryaboutavulnerabilityarisingfrom

improper validation of the LSRR.Pointereld.

If the address in the Destination Addresseldhasbeenreached,andthe

optionisnotempty,thenextaddressinthesourceroutereplacestheaddress

in the Destination Addresseld.

The IP address of the interface that will be used to forward this datagram

shouldberecordedintotheLSRR.However,beforewritingintheroute data

area,thefollowingcheckshouldbeperformed:

LSRR.Length – LSRR.Pointer>=3

This assures that there will be at least 4 bytes of space in which to record the

IP address. If the packet does not pass this check it should be dropped.

Anoffsetof“1”correspondstotheoptiontype,that’swhytheperformed

checkisLSRR.Length–LSRR.Pointer>=3,andnotLSRR.Length–LSRR.

Pointer>=4.

The LSRR must be copied on fragmentation. This means that if a packet that

carriestheLSRRisfragmented,eachofthefragmentswillhavetogothroughthelistofsystemsspeciedintheLSRRoption.

3.13.2.4 Strict Source and Record Route (SSRR) (Type = 137)

This option allows the originating system to specify a number of intermediate

systems a packet must pass through to get to the destination host.

Additionally,theroutefollowedbythepacketisrecordedintheoption,and

thedestinationhost(end-system)mustusethereverseofthepathcontained

in the received SSRR option.

This is similar to the LSRR option with the only difference that in the case of

SSRRtheroutespeciedintheoptionistheexactroutethepacketmusttake

(i.e.,nootherinterveningroutersareallowedtobeintheroute).

The SSSR option can be of help in debugging some network problems. Some

ISP Internet Service Provider) peering agreements require support for this

option in the routers within the peer of the ISP.

TheSSRRoptionhaswell-knownsecurityimplications.Amongotherthings,

the option can be used to:



27


• Bypassrewallrules

• Reach otherwise unreachable internet systems

• Establish TCP connections in a stealthy way

• Learn about the topology of a network

• Performbandwidth-exhaustionattacks

Oftheseattackvectors,theonethathasprobablyreceivedleastattentionis

theuseoftheSSRRoptiontoperformbandwidthexhaustionattacks.The

SSRRoptioncanbeusedasanamplicationmethodforbandwidth-

exhaustionattacksasanattackercouldmakeapacketbouncemultipletimes

between a number of systems by carefully crafting an LSRR option.

ThisistheIPv4-versionoftheIPv6amplicationattackthatwaswidely

publicisedin2007[BiondiandEbalard,2007].Theonlydifferenceisthatthe

maximumlengthfortheIPv4header(andhencetheSSRRoption)limitsthe

amplicationfactorwhencomparedtotheIPv6counter-part.

While the SSSR option may be of help in debugging some network problems

its security implications outweigh any legitimate use of it.

Allsystemsshould,bydefault,dropIPpacketsthatcontainanLSRRoption.

However,theyshouldprovideasystem-widetoggletoenablesupportforthis

optionforthosescenariosinwhichthisoptionisrequired.Suchsystem-wide

toggle should default to “off” (or “disable”).

[OpenBSD,1998]isasecurityadvisoryaboutanimproperimplementationof

suchasystem-widetogglein4.4BSDkernels.

ShouldprocessingoftheSSRRoptionbeexplicitlyenabledtherearesome

sanity checks that should be performed.

RFC791statesthatthisoptionshouldappear,atmost,onceinagiven

packet.Thus,ifapacketisfoundtohavemorethanoneSSRRoptionit

shouldbedropped.Also,ifapacketcontainsacombinationofSSRRand

LSRR options it should be dropped.

As the SSRR option is meant to specify the route a packet should follow from

sourcetodestination,useofmorethanoneSSRRoptioninasinglepacket

would be nonsensical. Therefore hosts and routers should check the IP

header and discard the packet if it contains more than one SSRR option or a

combination of LSRR and SSRR options.

As with many other IP options the SSRR option contains a Lengtheldthat

indicatesthelengthoftheoption.Thelengtheldshouldbecheckedtobeat

least 3:

SSRR.Length>=3



28



Additionally,thefollowingcheckshouldbeperformedonthelengtheld:

SSRR.Offset + SSRR.Length < IHL *4



should be dropped.

The Pointereldisrelativetothisoption,withtheminimumlegalvaluebeing

4 and so the following check should be performed:

SSRR.Pointer>=4


Additionally,thePointereldshouldbeamultipleof4.Consequently,the


SSRR.Pointer % 4 == 0


If the packet passes the above checks the receiving system should determine

whether the Destination Address of the packet corresponds to one of its IPaddresses.Ifdoesnot,itshouldbedropped.

ContrarytotheIPLooseSourceandRecordRoute(LSRR)option,theSSRR

option does not allow in the route other routers than those contained in theoption.Ifthesystemimplementstheweakend-systemmodelitisallowedfor

the system to receive a packet destined to any of its IP addresses on any of itsinterfaces.Ifthesystemimplementsthestrongend-systemmodelapacket

destined to it can be received only on the interface that corresponds to the IPaddress contained in the Destination Addresseld[Braden,1989].

If the packet passes this check the receiving system should determine

whether the source route is empty or not. The option is empty if:

SSRR.Pointer>SSRR.Length

Inthatcase,iftheaddressinthedestinationeldhasnotbeenreachedthe

packet should be dropped.

[Microsoft,1999]isasecurityadvisoryaboutavulnerabilityarisingfrom

improper validation of the SSRR.Pointereld.

Iftheoptionisnotempty,andtheaddressintheDestination Address eld

hasbeenreached,thenextaddressinthesourceroutereplacestheaddress



29


in the Destination Addresseld.ThisIPaddressmustbereachablewithout

theuseofanyinterveningrouter(i.e.,theaddressmustbelongtoanyofthe

networks to which the system is directly attached). If that is not the case the

packet should be dropped.

The IP address of the interface that will be used to forward this datagram

shouldberecordedintotheSSRR.However,beforedoingthat,thefollowing

check should be performed:

SSRR.Length – SSRR.Pointer>=3

Anoffsetof“1”correspondstotheoptiontype,that’swhytheperformed

check is SSRR.Length – SSRR.Pointer>=3,andnotSSRR.Length –SSRR.Pointer >=4.

This assures that there will be at least 4 bytes of space on which to record theIP address. If the packet does not pass this check it should be dropped.

The SSRR option must be copied on fragmentation. This means that if a

packetthatcarriestheSSRRisfragmented,eachofthefragmentswillhave

togothroughthelistofsystemsspeciedintheSSRRoption.

3.13.2.5 Record Route (Type = 7)

This option provides a means to record the route that a given packet follows.

Theoptionbeginswithan8-bitoptioncodewhichmustbeequalto7.The

secondbyteistheoptionlength,whichincludestheoption-typebyte,the

option-lengthbyte,thepointer byte,andtheactualoption-data. The third

byteisapointerintotheroutedata,indicatingtherstbyteoftheareain

whichtostorethenextroutedata.Thepointerisrelativetotheoptionstart.

RFC791statesthatthisoptionshouldappearonce,atmost,inagiven

packet.Therefore,ifapackethasmorethanoneinstanceofthisoptionit

should be dropped.

Giventheformatoftheoption,theLengtheldshouldbecheckedtobeatleast 3:

RR.Length>=3


Additionally,thefollowingcheckshouldbeperformedontheLengtheld:

RR.Offset + RR_Length < IHL *4



30




should be dropped.

Thepointereldisrelativetothisoption,withtheminimumlegalvaluebeing4. Therefore the following check should be performed:

RR.Pointer >=4

If the packet does not pass this check it should be silently dropped.

Additionally,thePointer eldshouldbeamultipleof4.Consequently,the


RR.Pointer % 4 == 0


WhenasystemreceivesanIPpacketwiththeRecordRouteoption,itshould

check whether there is space in the option to store route information. The

option is full if:

RR.Pointer>RR.Length

Iftheoptionisfull,thedatagramshouldbeforwardedwithoutfurther

processingofthisoption.Ifnot,thefollowingcheckshouldbeperformedbefore writing any route data into the option:

RR.Length - RR.Pointer>=3

Anoffsetof“1”correspondstotheoptiontype,that’swhytheperformedcheckis

LSRR.Length – LSRR.Pointer>=3,andnotLSRR.Length – LSRR.Pointer >=4.

If the packet does not pass this check the packet should be considered in

error and therefore should be silently dropped.

Iftheoptionisnotfull(i.e.,RR.Pointer <= RR.Length),butRR.Length –RR.Pointer<3,itmeansthatwhilethere’sspaceintheoption,thereisnot

enough space to store an IP address. It is fair to assume that such a scenariowill only occur when the packet has been crafted.

If the packet passes this check the IP address of the interface that will be

used to forward this datagram should be recorded into the area pointed by

the RR.Pointer,andRR.Pointer should then be incremented by 4.

Thisoptionisnotcopiedonfragmentationandappearsintherstfragment

only. If a fragment other than the one with offset 0 contains the Record Route

option it should be dropped.



3


TheRecordRouteoptioncanbeexploitedtolearnaboutthetopologyofa

network,asitallowsanattackertorecord.

3.13.2.6 Stream Identier (Type = 136)

TheStreamIdentieroptionoriginallyprovidedameansforthe16-bitSATNET

streamIdentiertobecarriedthroughnetworksthatdidnotsupportthe

stream concept.

However,asstatedbySection4.2.2.1ofRFC1812[Baker,1995],thisoption

is obsolete. Therefore it should be ignored by the processing systems.

Inthecaseoflegacysystemsstillusingthisoption,thelengtheldofthe

option should be checked to be 4. If the option does not pass this check it

should be dropped.

RFC 79 states that this option appears at most once in a given datagram. If

a packet contains more than one instance of this option it should be dropped.

3.13.2.7 Internet Timestamp (Type = 68)

This option provides a means for recording the time at which each system

processed this datagram. The timestamp option has a number of security

implications such as:

• It allows an attacker to obtain the current time of the systems thatprocessthepacket,whichtheattackermayndusefulinanumberof

scenarios.

• Itmaybeusedtomapthenetworktopology,inasimilarwaytotheIP

Record Route option.

• Itmaybeusedtongerprinttheoperatingsysteminusebyasystem

processing the datagram.

• Itmaybeusedtongerprintphysicaldevices,byanalysingtheclock

skew.

Therefore,bydefault,thetimestampoptionshouldbeignored.

Forthosesystemsthathavebeenexplicitlyconguredtohonorthisoption,

the rest of this subsection describes some sanity checks that should be

enforced on the option before further processing.

The option begins with an option-type byte which must be equal to 68. The

second byte is the option-length which includes the option-typebyte,the

option-lengthbyte,thepointer and the overow/ag byte. The minimum

legalvaluefortheoption-lengthbyteis4,whichcorrespondstoanInternet

Timestamp option that is empty (no space to store timestamps). Therefore

upon receipt of a packet that contains an Internet Timestamp option thefollowing check should be performed:



32


IT.Length>=4


Thefollowingcheckshouldalsobeperformedontheoptionlengtheld:

IT.Offset + IT.Length < IHL *4



should be dropped.

The pointerbytepointstotherstbyteoftheareainwhichthenext

timestamp data should be stored. As its value is relative to the beginning of

theoptionitsminimumlegalvalueis5.Consequently,thefollowingcheck

should be performed on a packet that contains the Internet Timestampoption:

IT.Pointer >=5


The ag eldhasthreepossiblelegalvalues:

• 0:Recordtimestampsonly,storedinconsecutive32-bitwords.

• : Record each timestamp preceded with the internet address of the

registering entity.

• 3:Theinternetaddresseldsoftheoptionarepre-specied.AnIP

module only registers its timestamp if it matches its own address with

thenextspeciedinternetaddress.

Therefore the following check should be performed:

IT.Flag == 0 || IT.Flag == || IT.Flag == 3


The timestampeldisaright-justied32-bittimestampinmillisecondssince

UT.Ifthetimeisnotavailableinmilliseconds,orcannotbeprovidedwith

respecttoUT,thenanytimemaybeinsertedasatimestamp,providedthe

highorderbitofthetimestampisset,toindicatethisnon-standardvalue.

AccordingtoRFC791,theinitialcontentsofthetimestampareamustbe

initialisedtozero,orinternetaddress/zeropairs.However,internetsystems

shouldbeabletohandlenon-zerovaluespossiblydiscardingtheoffending

datagram.



33


When an internet system receives a packet with an Internet Timestamp option

itdecideswhetheritshouldrecorditstimestampintheoption.Ifso,,itshould

determine whether the timestamp data area is full by means of the following

check:

IT.Pointer> IT.Length

Ifthisconditionistruethetimestampdataareaisfull.Ifnot,thereisroomin

the timestamp data area.

Ifthetimestampdataareaisfull,theoverowbyteshouldbeincremented,

and the packet should be forwarded without inserting the timestamp. If the

overowbyteitselfoverowsthepacketshouldbedropped.

If timestamp data area is not full further checks should be performed before

actually inserting any data.

• If the IT.Flag byte is 0 the following check should be performed:

IT.Length – IT.Pointer >=3

If the packet does not pass this check it should be dropped. If the packet

passesthischeckthereisroomforatleastone32-bittimestamp.The

system’s32-bittimestampshouldbeinsertedattheareapointedbythe

pointerbyte,andthepointerbyteshouldbeincrementedbyfour.

• If the IT.Flag byte is then the following check should be performed:

IT.Length–IT.Pointer>=7

If the packet does not pass this check it should be dropped. If the packet

does pass this check it means there is space in the timestamp data area to

storeatleastoneIPaddressplusthecorresponding32-bittimestamp.TheIP

address of the system should be stored at the area pointed to by the pointer

byte,followedbythe32-bitsystemtimestamp.Thepointerbyteshouldthen

be incremented by 8.

• Iftheagbyteis3thenthefollowingcheckshouldbeperformed:

IT.Length – IT.Pointer>=7

If the packet does not pass this check it should be dropped. If it does it

means there is space in the timestamp data area to store an IP address and

storethecorresponding32-bittimestamp.Thesystem’stimestampshouldbe

stored at the area pointed by IT.Pointer + 4. The pointer byte should be

incremented by 8.



34


[Kohnoetal,2005]describesatechniqueforngerprintingdevicesby

measuringtheclockskew.Itexploits,amongotherthings,thetimestamps

that can be obtained by means of the ICMP timestamp request messages

[Postel,1981].Thesamengerprintingmethodcouldbeimplementedwith

the aid of the Internet Timestamp option.

3.13.2.8 Router Alert (Type = 148)

TheRouterAlertoptionisdenedinRFC2113[Katz,1997].Ithasthe

semantic“routersshouldexaminethispacketmoreclosely”.Apacketthat

containsaRouterAlertoptionwillnotgothroughtherouter’sfast-pathand

will be processed in the router more slowly than if the option were not set.

Therefore this option may impact the performance of the systems that handle

the packet carrying it.

AccordingtothesyntaxoftheoptionasdenedinRFC2113,thefollowing

check should be enforced:

RA.Length == 4

Ifthepacketdoesnotpassthischeckitshouldbedropped.Furthermore,the

following check should be performed on the Valueeld:

RA.Value == 0


AsexplainedinRFC2113hostsshouldignorethisoption.

3.13.2.9 Probe MTU (Type =11)

ThisoptionisdenedinRFC1063[Moguletal,1988]andoriginallyprovided

amechanismtodiscoverthePath-MTU.

This option is obsolete and therefore any packet that is received containing

this option should be dropped.

3.13.2.10 Reply MTU (Type = 12)

ThisoptionisdenedinRFC1063[Moguletal,1988]andoriginallyprovided

amechanismtodiscoverthePath-MTU.

This option is obsolete and therefore any packet that is received containing




35


3.13.2.11 Traceroute (Type = 82)

ThisoptionisdenedinRFC1393[Malkin,1993],andoriginallyprovideda

mechanism to trace the path to a host.

Thisoptionisobsolete,andthereforeanypacketthatisreceivedcontaining


3.13.2.12 DoD Basic Security Option (Type = 130)

Thisoptionisusedbyend-systemsandintermediatesystemsofaninternet

to[Kent,1991]:

• Transmit from source to destination in a network standard

representation the common security labels required by computer

security models.

• Validate the datagram as appropriate for transmission from the source

and delivery to the destination.

• Ensure that the route taken by the datagram is protected to the level

required by all protection authorities indicated on the datagram.

ItisspeciedbyRFC1108[Kent,1991](whichobsoletesRFC1038[St.

Johns,1988]).

RFC791[Postel,1981]denedthe“SecurityOption”(Type=130),which

usedthesameoptiontypeastheDoDBasicSecurityoptiondiscussedinthis

section.The“SecurityOption”speciedinRFC791isconsideredobsoleteby

Section4.2.2.1ofRFC1812,andthereforethediscussioninthissectionis

focusedontheDoDBasicSecurityoptionspeciedbyRFC1108[Kent,

1991].

Section4.2.2.1ofRFC1812statesthatrouters“SHOULDimplementthis

option”.

TheDoDBasicSecurityOptioniscurrentlyimplementedinanumberof

operatingsystems(e.g.[IRIX,2008],[SELinux,2008],[Solaris,2008],and

[Cisco,2008]),anddeployedinanumberofhigh-securitynetworks.

RFC 08 states that the option should appear once in a datagram at the

most.IfmorethanoneDoDBasicSecurityoption(BSO)appearsinagiven

datagram the corresponding datagram should be dropped.

RFC 08 states that the option Length is variable with a minimum option

Length of 3 bytes. Therefore the following check should be performed:

BSO.Length>=3




36


Systems that belong to networks in which this option is in use should process

theDoDBasicSecurityoptioncontainedineachpacketasspeciedin[Kent,

1991].

CurrentdeploymentsoftheDoDSecurityOptionshavemotivatedtheproposalof a “Common Architecture Label IPv6 Security Option (CALIPSO)” for the IPv6protocol.[St.Johnsetal,2008].

3.13.2.13 DoD Extended Security Option (Type = 133)

Thisoptionpermitsadditionalsecuritylabelinginformation,beyondthat

presentintheBasicSecurityOption(Section3.13.2.12),tobesuppliedinan

IPdatagramtomeettheneedsofregisteredauthorities.ItisspeciedbyRFC

1108[Kent,1991].

ThisoptionmaybepresentonlyinconjunctionwiththeDoDBasicSecurityoption.ThereforeifapacketcontainsaDoDExtendedSecurityoption(ESO),

butdoesnotcontainaDoDBasicSecurityoption,itshouldbedropped.It

shouldbenotedthat,unliketheDoDBasicSecurityoption,thisoptionmay

appear multiple times in a single IP header.

RFC1108statesthattheoptionLengthisvariable,withaminimumoption

Length of 3 bytes. Therefore the following check should be performed:

ESO.Length>=3



theDoDExtendedSecurityoptioncontainedineachpacketasspeciedin

RFC1108[Kent,1991].

3.13.2.14 Commercial IP Security Option (CIPSO) (Type = 134)

This option was proposed by the Trusted Systems Interoperability Group

(TSIG) with the intent of meeting trusted networking requirements for the

commercialtrustedsystemsmarketplace.Itisspeciedin[CIPSO,1992]and[FIPS,1994].

The TSIG proposal was taken to the Commercial Internet Security Option(CIPSO)WorkingGroupoftheIETF[CIPSOWG,1994],andanInternet-Draft

wasproduced[CIPSO,1992].TheInternet-Draftwasneverpublishedasan

RFC,andtheproposalwaslaterstandardisedbytheU.S.NationalInstituteof

Standards and Technology (NIST) as “Federal Information Processing StandardPublication188”[FIPS,1994].

Itiscurrentlyimplementedinanumberofoperatingsystems(e.g.IRIX[IRIX,

2008],Security-EnhancedLinux[SELinux,2008],andSolaris[Solaris,2008])

anddeployedinanumberofhigh-securitynetworks.



37


[ZakrzewskiandHaddad,2002]and[HaddadandZakrzewski,2004]provide

anoverviewofaLinuximplementation.

Accordingtotheoptionsyntaxspeciedin[CIPSO,1992]thefollowing

validation check should be performed:

CIPSO.Length>=6



theCIPSOoptioncontainedineachpacketasspeciedin[CIPSO,1992].

3.13.2.15 Sender Directed Multi-Destination Delivery (Type = 149)

ThisoptionisdenedinRFC1770[Graff,1995],andoriginallyprovidedunreliableUDPdeliverytoasetofaddressesincludedintheoption.

This option is obsolete. If a received packet contains this option it should be

dropped.

3.14 Differentiated Services eld

TheDifferentiatedServicesArchitectureisintendedtoenablescalableservice

discriminationintheInternetwithouttheneedforper-owstateandsignalingateveryhop

[Blakeetal,1998].RFC2474[Nicholsetal,1998]denesaDifferentiated Services Field (DSField),whichisintendedtosupersedetheoriginalType of Serviceeld.Figure

4showstheformatoftheeld.

Figure5:StructureoftheDSField

The DSCP (“Differentiated Services CodePoint”) is used to select the treatment the

packetistoreceivewithintheDifferentiatedServicesDomain.TheCU (“Currently

Unused”)eldwas,atthetimethespecicationwasissued,reservedforfutureuse.The

DSCPeldisusedtoselectaPHBbymatchingagainsttheentire6-biteld.

Considering that the DSCPelddetermineshowapacketistreatedwithinaDSdomain,

an attacker sends packets with a forged DSCPeldtoperformatheftofserviceoreven



38


aDenialofServiceattack.Inparticular,anattackercouldforgepacketswithacodepoint

ofthetype‘11x000’which,accordingtoSection4.2.2.2ofRFC2474[Nicholsetal,

1998],wouldgivethepacketspreferentialforwardingtreatmentwhencomparedwiththe

PHBselectedbythecodepoint‘000000’.Ifstrictpriorityqueuingwereutilised,a

continuousstreamofsuchpocketscouldperformaDenialofServicetootherowswhichhave a DSCP of lower relative order.

As the DSeldisincompatiblewiththeoriginalType of Serviceeld,bothDSdomains

and networks using the original Type of Serviceeldshouldprotectthemselvesbyre-

markingthecorrespondingeldwhereappropriate,probablydeployingremarking

boundary nodes. Care must be taken so that packets received with an unrecognised

DSCP do not cause the handling system to malfunction.

3.15 Explicit Congestion Notication (ECN)

RFC3168[Ramakrishnanetal,2001]speciesamechanismforrouterstosignal

congestiontohostssendingIPpacketsbymarkingtheoffendingpackets,ratherthan

discardingthem.RFC3168denestheECNeldwhichutilisestheCUunusedeldof

the DSCPelddescribedinSection3.14ofthisdocument.Figure5showsthesyntaxof

the ECNeld,togetherwiththeDSCPeldusedforDifferentiatedServices.

Figure6:TheDifferentiatedServicesandECNeldsinIP

Assuch,theECNelddenesfourcodepoints:

ECN eld Codepoint

00 Not-ECT

0 ECT()

0 ECT(0) CE

The security implications of ECN are discussed in detail in a number of Sections of RFC

3168.OfthepossiblethreatsdiscussedintheECNspecicationwebelievethatonethat

canbeeasilyexploitedisthehostfalselyindicatingECN-Capability.

An attacker could set the ECT codepoint in the packets it sends to signal the network that

theendpointsofthetransportprotocolareECN-capable.Consequently,when

experiencingmoderatecongestion,routersusingactivequeuemanagementbasedon



39


REDwouldmarkthepackets(withtheCEcodepoint)ratherthandiscardthem.Inthe

samescenario,packetsofcompetingowsthatdonothavetheECTcodepointset

would be dropped. Therefore an attacker would get better network service than the

competingows.

However if this moderate congestion turned into heavy congestion routers should switch

todroppackets,regardlessofwhetherthepacketshavetheECTcodepointsetornot.

A number of other threats could arise if an attacker was a man in the middle (i.e. was in

the middle of the path the packets travel to get to the destination host). For a detailed

discussionofthosecases,weurgethereadertoconsultSection16ofRFC3168.



40


4. Internet Protocol Mechanisms

4.1 Fragment reassembly

ToaccommodatenetworkswithdifferentMaximumTransmissionUnits(MTUs)the

InternetProtocolprovidesamechanismforthefragmentationofIPpacketsbyend-

systems(hosts)and/orintermediatesystems(routers).Reassemblyoffragmentsis

performedonlybytheend-systems.

[CerfandKahn,1974]providestherationaleforwhichpacketreassemblyisnotperformed

by intermediate systems.

DuringthelastfewdecadesIPfragmentationandreassemblyhasbeenexploitedina

numberofwaystoperformactionssuchasevadingNetworkIntrusionDetectionSystems

(NIDS),bypassingrewallrules,andperformingDenialofService(DoS)attacks.

[Bendi1998]and[Humble,1998]areexamplesoftheexploitationoftheseissuesfor

performingDenialofService(DoS)attacks.[CERT,1997]and[CERT,1998b]document

theseissues.[Anderson,2001]isasurveyoffragmentationattacks.[US-CERT,2001]isan

exampleoftheexploitationofIPfragmentationtobypassrewallrules.[CERT,1999]

describestheimplementationoffragmentationattacksinDistributedDenialofService

(DDoS)attacktools.

ThebasicproblemwithIPfragmentreassemblyisthecomplexityofthefunctionina

number of aspects:

• Fragment reassembly is a stateful operation for a stateless protocol (IP). The IPmodule at the host performing the reassembly function must allocate memory

buffers both for temporarily storing the received fragments and to perform the

reassemblyfunction.Attackerscanexploitthisfacttoexhaustmemorybuffersat

the system performing the fragment reassembly.

• The fragmentation and reassembly mechanisms were designed at a time in which

the available bandwidths were very different from the bandwidths available now.

With the currently available bandwidths a number of interoperability problems may

ariseandtheseissuesmaybeintentionallyexploitedbyattackerstoperformDenial

ofService(DoS)attacks.

• Fragment reassembly must usually be performed without any knowledge of the

properties of the path the fragments follow. Without this information hosts cannot

make any educated guess on how long they should wait for missing fragments to

arrive.

• Thefragmentreassemblyalgorithm,asdescribedbytheIETFspecicationsis

ambiguousandallowsforanumberofinterpretations,eachofwhichhasfound

placeindifferentTCP/IPstackimplementations.

• Thereassemblyprocessissomewhatcomplex.Fragmentsmayarriveoutoforder,duplicated,overlapping,etc.andthiscomplexityhasleadtonumerousbugsin

different implementations of the IP protocol.



4


4.1.1 Problems related with memory allocation

WhenanIPdatagramisreceivedbyanend-systemitwillbetemporarily

stored in system memory until the IP module processes it and hands it to the

protocol machine that corresponds to the encapsulated protocol.

InthecaseoffragmentedIPpackets,whiletheIPmodulemayperform

preliminary processing of the IP header (such as checking the header for

errorsandprocessingIPoptions),fragmentsmustbekeptinsystembuffers

until all fragments are received and are reassembled into a complete internet

datagram.

Asmentionedabove,becausetheinternetlayerwillnotusuallyhave

information about the characteristics of the path between the system and the

remotehost,noeducatedguesscanbemadeontheamountoftimethat

shouldbewaitedfortheotherfragmentstoarrive.Therefore,the

specicationsrecommendtowaitforaperiodoftimethatwillbeacceptable

for virtually all the possible network scenarios in which the protocols might

operate.Specically,RFC1122[Braden,1989]statesthatthereassembly

timeoutshouldbeaxedvaluebetween60and120seconds.Ifafterwaiting

forthatperiodoftimetheremainingfragmentshavenotyetarrived,allthe

received fragments for the corresponding packet are discarded.

TheoriginalIPSpecication,RFC791[Postel,1981],statesthatsystems

should wait for at least 5 seconds for the missing fragments to arrive.Systemsthatfollowthe“ExampleReassemblyProcedure”describedin

Section 3.2 of RFC 79 may end up using a reassembly timer of up to 4.25minutes,withminimumof15seconds.Section3.3.2(“Reassembly”)ofRFC

1122correctedthisadvice,statingthatthereassemblytimeoutshouldbea

xedvaluebetween60and120seconds.

However,thelongerthesystemwaitsforthemissingfragmentstoarrive,the

longer the corresponding system resources must be tied to the corresponding

packet.Theamountofsystemmemoryisniteandevenwithtoday’ssystems

it can still be considered a scarce resource.

An attacker could take advantage of the uncomfortable situation the system

performing fragment reassembly is in by sending forged fragments that willneverreassembleintoacompletedatagram.Thatis,anattackerwouldsend

manydifferentfragments,withdifferentIPIDs,withouteversendingallthe

necessary fragments that would be needed to reassemble them into a full IP

datagram. For each of the fragments the IP module would allocate resources

and tie them to the corresponding fragment until the reassembly timer for the

correspondingpacketexpires.

There are some implementation strategies which could increase the impact of

thisattack.Forexample,uponreceiptofafragment,somesystemsallocatea

memory buffer that will be large enough to reassemble the whole datagram.



42


Whilethismightbebenecialinlegitimatecases,thisjustampliestheimpact

ofthepossibleattacks,asasinglesmallfragmentcouldtieupmemory

buffersforthesizeofanextremelylarge(andunlikely)datagram.The

implementationstrategysuggestedinRFC815[Clark,1982]leadstosuchan

implementation.

The impact of the aforementioned attack may vary depending on some

specicimplementationdetails:

• If the system does not enforce limits on the amount of memory that can

be allocated by the IP module then an attacker could tie all system

memory to fragments at which point the system would become

unusable,probablycrashing.

• If the system enforces limits on the amount of memory that can be

allocated by the IP module as a whole then when this limit is reached allfurther IP packets that arrive would be discarded until some fragments

time out and free memory is available again.

• If the system enforces limits on the amount memory that can be

allocated for the reassembly of fragments (in addition to enforcing a

limitfortheIPmoduleasawhole)thenwhenthislimitisreached,all

further fragments that arrive would be discarded until some fragment(s)

time out and free memory is available again.

4.1.2 Problems that arise from the length of the IP Identication eld

The Internet Protocols are currently being used in environments that are quite

differentfromtheonesinwhichtheywereconceived.Forinstance,the

availability of bandwidth at the time the Internet Protocol was designed was

completely different from the availability of bandwidth in today’s networks.

The Identicationeldisa16-biteldthatisusedforthefragmentationand

reassemblyfunction.Intheeventadatagramgetsfragmented,allthe

corresponding fragments will share the same Identicationnumber.Thus,

the system receiving the fragments will be able to uniquely identify them as

fragments that correspond to the same IP datagram. At a given point in timethere must be at most only one packet in the network with a given

Identicationnumber.Ifnot,anIdentication number “collision” might

occurandthereceivingsystemmightendup“mixing”fragmentsthat

correspond to different IP datagrams which simply reused the same

Identication number.

For each group of fragments whose Identication numbers “collide” the

fragment reassembly will lead to corrupted packets. The IP payload of the

reassembled datagram will be handed to the corresponding upper layer

protocol,wheretheerrorwill(hopefully)bedetectedbysomeerrordetecting

code (such as the TCP checksum) and the packet will be discarded.



43


Anattackercouldexploitthisfacttointentionallycauseasystemtodiscardall

orpartofthefragmentedtrafcitgets,thusperformingaDenialofService

attack.Suchanattackerwouldsimplyestablishaowoffragmentswith

differentIPIdenticationnumberstotrashallorpartoftheIPIdentication

space.Asaresult,thereceivingsystemwouldusetheattacker’sfragmentsforthereassemblyoflegitimatedatagrams,leadingtocorruptedpackets

which would later (and hopefully) get dropped.

Inmostcases,useofalongfragmenttimeoutwillbenettheattackeras

forgedfragmentswillkeeptheIPIdenticationspacetrashedforalonger

period of time.

4.1.3 Problems that arise from the complexity of the reassembly

algorithm

AsIPpacketscanbeduplicatedbythenetwork,andeachpacketmaytakea

differentpathtogettothedestinationhost,fragmentsmayarrivenotonlyout

oforderand/orduplicated,butalsooverlapping.Thismeansthatthe

reassemblyprocesscanbesomewhatcomplexwiththecorresponding

implementationbeingnotspecicallytrivial.

[Shannonetal,2001]analysesthecausesandattributesoffragmenttrafc

measured in several types of WANs.

Duringtheyears,anumberofattackshaveexploitedbugsinthereassembly

functionofanumberofoperatingsystems,producingbufferoverowsthathaveled,inmostcases,toacrashoftheattackedsystem.

4.1.4 Problems that arise from the ambiguity of the reassembly

process

NetworkIntrusionDetectionSystems(NIDSs)typicallymonitorthetrafcona

givennetworkwiththeintentofidentifyingtrafcpatternsthatmightindicate

network intrusions.

InthepresenceofIPfragments,inordertodetectillegitimateactivityatthe

transportorapplicationlayers(i.e.,anyprotocollayerabovethenetwork

layer),aNIDSmustperformIPfragmentreassembly.

Inordertocorrectlyassessthetrafc,theresultofthereassemblyfunction

performedbytheNIDSshouldbethesameasthereassemblyfunction

performed by the intended recipient of the packets.

However a number of factors make the result of the reassembly process

ambiguous:

• TheIETFspecicationsareambiguousastowhatshouldbedone



44


whenoverlappingfragmentswerereceived.Thus,inthepresenceof

overlappingdata,thesystemperformingthereassemblyfunctionisfree

toeitherhonortherstsetofdatareceived,thelatestcopyreceived,or

any other copy received in between.

• Asthespecicationsdonotenforceanyspecicfragmenttimeout

value,differentsystemsmaychoosedifferentvaluesforthefragment

timeout. This means that given a set of fragments received at some

speciedtimeintervalssomesystemswillreassemblethefragments

into a full datagram while others may timeout the fragments and

therefore drop them.

• AsthefragmentbuffersgetfullaDenialofService(DoS)conditionwill

occurunlesssomeactionistaken.Manysystemsushpartofthe

fragmentbufferswhensomethresholdisreached.Thus,dependingon

fragmentload,timingissuesandushingpolicy,aNIDSmayget

incorrect assumptions about how (and if) fragments are being

reassembled by their intended recipient.

Asoriginallydiscussedby[PtacekandNewsham,1998],theseissuescanbe

exploitedbyattackerstoevadeintrusiondetectionsystems.

ThereexistfreelyavailabletoolstoforcefullyfragmentIPdatagramstohelp

evadeIntrusionDetectionSystems.Fragrouter[Song,D.,1999]isan

exampleofsuchatool;itallowsanattackertoperformalltheevasion

techniquesdescribedin[PtacekandNewsham,1998].Ftester[Barisani,2006]isatoolthathelpstoauditsystemsregardingfragmentationissues.

4.1.5 Problems that arise from the size of the IP fragments

Oneapproachtofragmentlteringinvolveskeepingtrackoftheresultsof

applyinglterrulestotherstfragment(i.e.aFragment Offset of 0) and

applyingthemtosubsequentfragmentsofthesamepacket.Theltering

modulewouldmaintainalistofpacketsindexedbytheSource Address,

Destination Address,ProtocolandIdenticationnumber.Whentheinitial

fragmentisseen,iftheMFbitisset,alistitemwouldbeallocatedtoholdthe

resultoflteraccesschecks.Whenpacketswithanon-zeroFragmentOffsetcomein,lookupthelistelementwithamatchingSource Address/

Destination Address/Protocol/Identication and apply the stored result

(pass or block). When a fragment with a zero MFbitisseen,freethelist

element.Unfortunately,therulesofthistypeofpacketltercanusuallybe

bypassed.[Ziembaetal,1995]describesthedetailsoftheinvolved

technique.



46


fragments,andthosethataimtocauseacollisionofIPIdentication

numbers,thereareanumberofcounter-measuresthatcanbeimplemented.

The IP module should enforce a limit on the amount of memory that can be

allocatedforIPfragments,aswellasalimitonthenumberoffragmentsthatwill be allowed in the system at any time. This will basically limit the resources

spentonthereassemblyprocess,andpreventanattackerfromtrashingthe

whole system memory.

Additionally,theIPmoduleshouldkeepadifferentbufferforIPfragmentsthan

for complete IP datagrams. This will basically separate the effects of fragment

attacksonnon-fragmentedtrafc.MostTCP/IPimplementations,suchas

thatinLinuxandthoseinBSD-derivedsystems,alreadyimplementthis.

Evenwiththesecounter-measuresinplacethereisstilltheissueofwhatto

dowhenthebufferusedforIPfragmentsgetfull.Basically,ifthefragment

bufferisfull,noinstanceofcommunicationthatreliesonfragmentationwillbe

able to progress.

Unfortunately there are not many options for reacting to this situation. If

nothing is done all the instances of communication that rely on fragmentation

willexperienceadenialofservice.Thus,theonlythingthatcanbedoneis

ushallorpartofthefragmentbufferonthepremisethatlegitimatetrafcwill

beabletomakeuseofthefreedbufferspacetoallowcommunicationows

to progress.

There are a number of factors that should be taken into consideration when

ushingthefragmentbuffer.First,ifafragmentofagivenpacket(i.e.,

fragment with a given Identicationnumber)isushed,alltheother

fragmentsthatcorrespondtothesamedatagramshouldbeushed.Asin

order for a packet to be reassembled all of its fragments must be received by

the system performing the reassembly function. Flushing only a subset of the

fragments of a given packet would keep the corresponding buffers tied to

fragments that would never reassemble into a complete datagram. Care

mustbetakensothat,intheeventthatsubsequentbufferushesneedtobe

performed,itisnotalwaysthesamesetoffragmentsthatgetdroppedas

suchabehaviorwouldprobablycauseaselectiveDenialofService(DoS)tothetrafcowstowhichthatsetoffragmentsbelong.

ManyTCP/IPimplementationsdeneathresholdforthenumberoffragments

that,whenreached,triggerafragment-bufferush.Somesystemsush1/2

ofthefragmentbufferwhenthethresholdisreached.Asmentionedbefore,

this is to create some free space in the fragment buffer on the premise that

this will allow for new and legitimate fragments to be processed by the IP

module,thuslettingcommunicationsurvivetheoverwhelmingsituation.On

theotherhand,theideaofushingasomewhatlargeportionofthebufferis

toavoidushingalwaysthesamesetofpackets.



47


A more selective fragment buffer ushing strategy

Oneofthedifcultiesinimplementingcounter-measuresforthefragmentation

attacksdescribedinthisdocumentisthatitisdifculttoperformvalidation

checksonthereceivedfragments.Forinstance,thefragmentonwhichvaliditycheckscouldbeperformed,therstfragment,maybenottherst

fragment to arrive at the destination host.

Fragments can not only arrive out of order because of packet reordering

performedbythenetwork,butalsobecausethesystem(orsystems)that

fragmented the IP datagram may indeed transmit the fragments out of order.

AnotableexampleofthisistheLinuxTCP/IPstack,whichtransmitsthe

fragments in reverse order.

This means that we cannot enforce checks on the fragments for which we

allocatereassemblyresources,astherstfragmentwereceiveforagivenpacketmaybesomeotherfragmentthantherstone(theonewithan

Fragment Offset of 0).

However,whenwedecidetofreesomespaceinthefragmentbuffer,some

renementscanbedonetotheushingpolicy.Therstthingwewouldliketo

doistostopdifferenttypesoftrafcfrominterferingwitheachother.This

means,inprinciple,thatwedonotwantfragmentedUDPtrafctointerfere

withfragmentedTCPtrafc.Inordertoimplementthistrafcseparationfor

thedifferentprotocols,adifferentfragmentbufferwouldbeneeded,in

principle,foreachofthe256differentprotocolsthatcanbeencapsulatedin

an IP datagram.

We believe a tradeoff is to implement two separate fragment buffers: one for

IP datagrams that encapsulate IPsec packets and another for the rest of the

trafc.ThisbasicallymeansthattrafcnotprotectedbyIPsecwillnotinterfere

withthoseowsofcommunicationthatarebeingprotectedbyIPsec.

The processing of each of these two different fragment buffers would be

completely independent from each other. In the case of the IPsec fragment

buffer,whenthebufferneedstobeushedthefollowingrenedpolicycould

be applied:

• First,foreachpacketforwhichtheIPsecheaderhasbeenreceived

checkthattheSPIeldoftheIPsecheadercorrespondstoanexisting

IPsec Security Association (SA). And probably also check that the

IPsec sequence number is valid. If the check fails drop all the fragments

that correspond to this packet.

• Second,ifthefragmentbufferstillneedstobeusheddropallthe

fragments that correspond to packets for which the full IPsec header

has not yet been received. The number of packets for which this

ushingisperformeddependsontheamountoffreespacethatneedsto be created.



48


• Third,ifthereisstillnotenoughspaceinthefragmentbufferafter

ushingpacketswithinvalidIPsecinformation(Firststep),andpackets

onwhichvalidationcheckscouldnotbeperformed(Secondstep),

drop all the fragments that correspond to packets that passed the

checksoftherststepuntilthenecessaryfreespaceiscreated.

Therationalebehindthispolicyisthat,atthepointofushingthefragment

buffer,weprefertokeepthosepacketsonwhichwecouldsuccessfully

perform a number of validation checks over those packets on which those

checksfailed,orcouldnotbeperformed.

BycheckingboththeIPsecSPIandtheIPsecsequencenumber,itisvirtually

impossibleforanattackerthatisoff-pathtoperformaDenialofServiceattack

tocommunicationowsbeingprotectedbyIPsec.

UnfortunatelysomeTCP/IPstacks,whenperformingfragmentation,sendthe

correspondingfragmentsinreverseorder.Insuchcases,atthepointof

ushingthefragmentbuffer,legitimatefragmentswillreceivethesame

treatment as the possible forged fragments.

Thisrenedushingpolicyprovidesanincreasedlevelofprotectionagainst

thistypeofresourceexhaustionattack,whilenotmakingthesituationofout-

of-orderIPsec-securedtrafcworsethanwiththesimpliedushingpolicy

described in the previous section.

Reducing the fragment timeout

RFC1122[Braden,1989]statesthatthereassemblytimeoutshouldbea

xedvaluebetween60and120seconds.Therationalebehindtheselong

timeout values is that they should accommodate any path characteristics

suchaslong-delaypaths.Howeveritmustbenotedthatthistimerisreally

measuringinter-fragmentdelays,ormorespecically,fragmentjitter.

Ifallfragmentstakepathsofsimilarcharacteristics,theinter-fragmentdelay

willusuallybeafewsecondsatmost.Nevertheless,eveniffragmentstake

different paths of different characteristics the recommended 60 to 20

secondsisexcessive.

Some systems have already reduced the fragment timeout to 30 seconds

[Linux,2006].Thefragmenttimeoutcouldprobablybefurtherreducedto

approximately15secondsalthoughfurtherresearchonthisissueis

necessary.

Itshouldbenotedthatinnetworkscenariosoflong-delayandhigh-

bandwidth(usuallyreferredtoas“Long-FatNetworks”),usingalongfragment

timeoutwouldlikelyincreasetheprobabilityofcollisionofIPIDnumbers.In

such scenarios it is mandatory to avoid the use of fragmentation with



49


techniquessuchasPMTUD[MogulandDeering,1990]orPLPMTUD[Mathis

andHeffner,2007].

Counter-measure for some IDS evasion techniques

[ShankarandPaxson,2003]introducesatechniquenamed“ActiveMapping”

thatpreventsevasionofaNIDSbyacquiringsufcientknowledgeaboutthe

network being monitored to assess which packets will arrive at the intended

recipientandhowtheywillbeinterpretedbyit.[Novak,2005]describessome

techniquesthatareappliedbytheSnortNIDStoavoidevasion.

Counter-measure for rewall-rules bypassing

Oneoftheclassicaltechniquestobypassrewallrulesinvolvessending

packets in which the header of the encapsulated protocol is fragmented. Even

whenitwouldbelegal(asfarastheIETFspecicationsareconcerned)to

receivesuchpackets,theMTUsofthenetworktechnologiesusedinpractice

are not so small as to require the header of the encapsulated protocol to be

fragmented.Therefore,thesystemperformingreassemblyshoulddropall

packetswhichfragmenttheupper-layerprotocolheader.Thenecessary

information to perform this check could be stored by the IP module together

withtherestoftheupper-layerprotocolinformation.

Additionally,giventhatmanymiddle-boxessuchasrewallscreatestate

accordingtothecontentsoftherstfragmentofagivenpacket,itisbestthat

intheeventanend-systemreceivesoverlappingfragmentsithonorstheinformationcontainedinthefragmentthatwasreceivedrst.

RFC1858[Ziembaetal,1995]describestheabuseofIPfragmentationto

bypassrewallrules.RFC3128[Miller,2001]correctssomeerrorsinRFC

858.

4.2 Forwarding

4.2.1 Precedence-ordered queue service

Section5.3.3.1ofRFC1812[Baker,1995]statesthatroutersshould

implementprecedence-orderedqueueservice.Thismeansthatwhena

packetisselectedforoutputona(logical)link,thepacketofhighest

precedence that as been queued for that link is sent. Section 5.3.3.2 of RFC

1812advicesrouterstodefaulttomaintainingstrictprecedence-ordered

service.

GiventhatitistrivialtoforgetheIPprecedenceeldoftheIPheader,an

attacker could simply forge a high precedence number in the packets it sends

toillegitimatelygetbetternetworkservice.Ifprecedence-orderedqueued

service is not required in a particular network infrastructure it should be



50


disabledandallpacketswouldreceivethesametypeofservice,despitethe

values in their Type of Service or Differentiated Serviceselds.

WhenPrecedence-orderedqueueserviceisrequiredinthenetwork

infrastructure in order to mitigate the attack vector discussed in the previousparagraph,edgeroutersorswitchesshouldbeconguredtopoliceand

remark the Type of Service or Differentiated Services values according to

thetypeofserviceatwhicheachend-systemhasbeenallowedtosend

packets.

Bullet4ofSection5.3.3.3ofRFC1812statesthatrouters“MUSTNOT

changeprecedencesettingsonpacketsitdidnotoriginate”.However,given

thesecurityimplicationsofthePrecedenceelditisfairforrouters,switches

orothermiddle-boxes,particularlythoseinthenetworkedge,tooverwritethe

Type of Service (or Differentiated Services)eldofthepacketstheyare

forwardingaccordingtoacongurednetworkpolicy.

Section5.3.3.1andSection5.3.6ofRFC1812statesthatifprecedence-

ordered queue service is implemented and enabled the router “MUST NOT

discard a packet whose precedence is higher than that of a packet that is not

discarded”. While this recommendation makes sense given the semantics of

thePrecedenceeld,itisimportanttonotethatitwouldbesimpleforan

attacker to send packets with forged high Precedence value to congest some

internetrouter(s)andcauseall(ormost)trafcwithalowerPrecedencevalue

to be discarded.

4.2.2 Weak Type of Service

Section 5.2.4.3 of RFC 82 describes the algorithm for determining the

next-hopaddress(i.e.,theforwardingalgorithm).Bullet3,“WeakTOS”,

addresses the case in which routes contain a “type of service” attribute. It

statesthatincaseapacketcontainsanon-defaultTOS(i.e.,0000)only

routes with the same TOS or with the default TOS should be considered for

forwardingthatpacket.However,thismeansthatamongstthelongestmatch

routes for a packet are routes with a TOS other than the one contained in the

receivedpacketandnorouteswiththedefaultTOS,thusthecorresponding

packet would be dropped. This may or may not be a desired behavior.

Analternativetothiswouldbe,incasesamongstthe“longestmatch”routes

thereareonlyrouteswithnon-defaulttypeofserviceswhichdonotmatchthe

TOScontainedinthereceivedpacket,,tousearoutewithanyotherTOS.

While this route would most likely not be able to address the type of service

requestedbypacket,itwould,atleast,providea“besteffort”service.

It must be noted that Section 5.3.2 of RFC 82 allows for routers for not

honoring the TOSeld.Therefore,theproposedalternativebehaviorisstill

compliantwiththeIETFspecications.



5


WhileofciallyspeciedintheRFCseries,TOS-basedroutingisnotwidely

deployed in the Internet.

4.2.3 Address Resolution

Inthecaseofbroadcastlink-layertechnologies,inorderforasystemto

transferanIPdatagramitmustusuallyrstmapanIPaddresstothe

correspondinglink-layeraddress(forexample,bymeansoftheARPprotocol

[Plummer,1982]).Thismeansthatwhilethisoperationisbeingperformedthe

packets that would require such a mapping would need to be kept in

memory. This may happen both in the case of hosts and in the case of

routers.

Thissituationmightbeexploitedbyanattackerwhichcouldsendalarge

amountofpacketstoanon-existenthostwhichwouldsupposedlybedirectlyconnected to the attacked router. While trying to map the corresponding IP

addressintoalink-layeraddress,theattackedrouterwouldkeepinmemory

allthepacketsthatwouldneedtomakeuseofthatlink-layeraddress.Atthe

pointinwhichthemappingfunctiontimesout,dependingonthepolicy

implementedbytheattackedrouter,onlythepacketthattriggeredthecallto

themappingfunctionmightbedropped.Inthatcase,thesameoperation

wouldberepeatedforeverypacketdestinedtothenon-existenthost.

Dependingonthetimeoutvalueforthemappingfunctionthissituationmight

lead to the router buffers to run out of free space with the consequence that

incominglegitimatepacketswouldhavetobedropped,orthatlegitimate

packetsalreadystoredintherouter’sbuffersmightgetdropped.Bothof

thesesituationswouldleadeithertoacompleteDenialofServiceortoa

degradation of the network service.

Onecounter-measuretothisproblemwouldbetodropatthepointthe

mapping function times out all the packets destined to the address that timed

out.Inaddition,a“negativecacheentry”mightbekeptinthemodule

performingthematchingfunction,sothatforsomeamountoftimethe

mapping function would return an error when the IP module requests to

perform a mapping for some address for which the mapping has recently

timed out.

A common implementation strategy for routers is that when a packet isreceived that requires an ARP request to be performed before the packet canbeforwarded,thepacketisdroppedandtherouteristhenengagedinthe

ARP procedure.

4.2.4 Dropping packets

In some scenarios it may be necessary for a host or router to drop packets

from the output queue. In the event one of such packets happens to be an IP

fragment,andtherewereotherfragmentsofthesamepacketinthequeue,



52


those other fragments should also be dropped. The rationale for this policy is

that it is nonsensical to spend system resources on those other fragments

because as long as one fragment is missing it will be impossible for the

receiving system to reassemble them into a complete IP datagram.

Some systems have been known to drop just a subset of fragments of a given

datagram,leadingtoadenialofservicecondition,asonlyasubsetofallthe

fragmentsofthepacketswereactuallytransferredtothenexthop.

4.3 Addressing

4.3.1 Unreachable addresses

It is important to understand that while there are some addresses that are

supposed to be unreachable from the public Internet (such as thosedescribedinRFC1918[Rekhteretal,1996],orthe“loopback”address),

there are a number of tricks an attacker can perform to reach them (e.g.

exploittheLSRRorSSRRIPoptions).Therefore,whenapplicable,packet

lteringshouldbeperformedatorganisationalnetworkboundarytoensure

that those addresses will be unreachable.

4.3.2 Private address space

The Internet Assigned Numbers Authority (IANA) has reserved the following

three blocks of the IP address space for private internets:

• 10.0.0.0-10.255.255.255(10/8prex)

• 172.16.0.0-172.31.255.255(172.16/12prex)

• 192.168.0.0-192.168.255.255(192.168/16prex)

UseoftheseaddressblocksisdescribedinRFC1918[Rekhteretal,1996].

Whereapplicable,packetlteringshouldbeperformedattheorganisational

perimeter to assure that these addresses are not reachable from outside the

enterprise network.

4.3.3 Class D addresses (224/4 address block)

TheClassDaddressescorrespondtothe224/4addressblockandareused

forInternetmulticast.ThereforeifapacketisreceivedwithaClassDaddress

as the Source Addressitshouldbedropped.Additionally,ifanIPpacket

with a multicast Destination Addressisreceivedforaconnection-oriented

protocol (e.g. TCP) the packet should be dropped.

4.3.4 Class E addresses (240/4 address block)

TheClassEaddressescorrespondtothe240/4addressblockandare



53


currentlyreservedforexperimentaluse.Asaresult,anumberof

implementations discard packets that contain a Class E address as the

Source Address or Destination Address.

ThereisongoingworktoreclassifytheClassE(240/4)addressblockasusableunicastaddressspaces[Fulleretal,2008a][Fulleretal,2008b][Wilson

etal,2007].Therefore,werecommendimplementationstoacceptaddresses

inthe240/4blockasvalidaddressesfortheSource Address and

Destination Address.

It should be noted that the broadcast address 255.255.255.255 still must be

treated as indicated in Section 4.3.7 of this document.

4.3.5 Broadcast and multicast addresses, and connection-oriented

protocols

Forconnection-orientedprotocols,suchasTCP,sharedstateismaintained

betweenonlytwoendpointsatatime.Therefore,ifanIPpacketwitha

multicast (or broadcast) Destination Addressisreceivedforaconnection-

orientedprotocol(e.g.TCP),thepacketshouldbedropped.

4.3.6 Broadcast and network addresses

TheIETFspecicationsdidnotoriginallypermitIPaddressestohavethe

value0or-1foranyoftheHostnumber,networknumberorsubnetnumber

elds,exceptforthecasesindicatedinSection4.3.7.HoweverthischangedfundamentallywiththedeploymentofClasslessInter-DomainRouting(CIDR)

[FullerandLi,2006]becausewithCIDRasystemcannotknowwhatthe

subnet mask is for a particular IP address.

Manysystemsnowallowadministratorstousethevalues0or-1forthose

elds.DespitethataccordingtotheIETFspecicationstheseaddressesare

illegal,modernIPimplementationsshouldconsidertheseaddressestobe

valid.

4.3.7 Special Internet addresses

RFC1812[Baker,1995]discussestheuseofsomespecialinternet

addresses,whichisofinteresttoperformsomesanitychecksontheSource

Address and Destination AddresseldsofanIPpacket.Itusesthe

following notation for an IP address:

{<Network-prex>,<Host-number>}

RFC1122[Braden,1989]containedasimilardiscussionofspecialinternet

addresses,includingsomeoftheform{<Network-prex>,<Subnet-number>,

<Host-number>}.However,asexplainedinSection4.2.2.11ofRFC1812,in

aCIDRworld,thesubnetnumberisclearlyanextensionofthenetworkprexandcannotbeinterpretedwithouttheremainderoftheprex.



54


{0, 0}

This address means “this host on this network”. It is meant to be used only

duringtheinitialisationprocedure,bywhichthehostlearnsitsownIP

address. If a packet is received with 0.0.0.0 as the Source Address for anypurposeotherthanbootstrapping,thecorrespondingpacketshouldbe

silently dropped. If a packet is received with 0.0.0.0 as the Destination

Address it should be silently dropped.

{0, Host number}

Thisaddressmeans“thespeciedhost,inthisnetwork”.Asintheprevious

case,itismeanttobeusedonlyduringtheinitialisationprocedurebywhich

the host learns its own IP address. If a packet is received with such an

address as the Source Addressforanypurposeotherthanbootstrapping,it

should be dropped. If a packet is received with such an address as the

Destination Address it should be dropped.

{-1, -1}

This address is the local broadcast address. It should not be used as a

source IP address. If a packet is received with 255.255.255.255 as the

Source Address it should be dropped.

Somesystems,whenreceivinganICMPechorequest,forexample,willuse

the Destination Address in the ICMP echo request packet as the Source Addressoftheresponsetheysend(inthiscase,anICMPechoreply).Thus,

whensuchsystemsreceivearequestsenttoabroadcastaddress,the

Source Address of the response will contain a broadcast address. Thisshouldbeconsideredabug,ratherthanamalicioususeofthelimited

broadcast address.

{Network number, -1}

Thisisthedirectedbroadcasttothespeciednetwork.Asrecommendedby

RFC2644[Senie,1999],routersshouldnotforwardnetwork-directed

broadcasts.Thisavoidsthecorrespondingnetworkfrombeingutilisedas,for

example,a“smurfamplier”[CERT,1998a].

AsnotedinSection4.3.6ofthisdocument,manysystemsnowallow

administratorstoconguretheseaddressesasunicastaddressesfornetwork

interfaces. In such scenarios routers should forward these addresses as if

they were traditional unicast addresses.

In some scenarios a host may have knowledge about a particular IP address

beinganetwork-directedbroadcastaddressratherthanaunicastaddress(e.

g.thatIPaddressisconguredonthelocalsystemasa“broadcast

address”). If a system can infer the Source Address of a received packet is anetwork-directedbroadcastaddressthepacketshouldbedropped.



55


AsnotedinSection4.3.6ofthisdocument,withthedeploymentofCIDR

[Fuler,2006],itmaybedifcultforasystemtoinferwhetheraparticularIP

address is a broadcast address.

{127, any}

This is the internal host loopback address. Any packet that arrives on any

physical interface containing this address as the Source Address,the

Destination Address,oraspartofasourceroute(eitherLSRRorSSRR)

should be dropped.

Forexample,packetswithaDestination Addressinthe127.0.0.0/8

address block that are received on an interface other than loopback should

be silently dropped. Packets received on any interface other than loopback

with a Source Address corresponding to the system receiving the packet

should also be dropped.



56


5. References

Anderson,J.2001. An Analysis of Fragmentation Attacks. Available at:

http://www.ouah.org/fragma.html

Almquist,P.1992.Type of Service in the Internet Protocol Suite. RFC 349.

Baker,F.1995.Requirements for IP Version 4 Routers. RFC 82.

Baker,F.,Savola,P.2004.Ingress Filtering for Multihomed Networks. RFC 3704.

Barisani,A.2006.FTester - Firewall and IDS testing tool. Available at:

http://dev.inversepath.com/trac/ftester

Bellovin,S.M.1989.Security Problems in the TCP/IP Protocol Suite. Computer CommunicationReview,Vol.19,No.2,pp.32-48.

Bellovin,S.M.2002. A Technique for Counting NATted Hosts.IMW’02,Nov.6-8,2002,Marseille,

France.

Bendi,1998.Boinkexploit.Availableat:

http://www.insecure.org/sploits/95.NT.fragmentation.bonk.html

Biondi,P.,Ebalard,A.2007.IPv6 Routing Header Security. CanSecWest 2007 Security Conference.

Available at: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf

Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.,andWeiss,W.,1998. An Architecture for

Differentiated Services. RFC 2475.

Braden,R.1989.Requirements for Internet Hosts -- Communication Layers. RFC 22.

Cerf,V.,andKahn,R.1974. A Protocol for Packet Network Intercommunication. IEEE Transactions on

Communications,Vol.22,No.5,May1974,pp.637-648.

CERT. 996a. CERT Advisory CA-1996-01: UDP Port Denial-of-Service Attack. Available at:

http://www.cert.org/advisories/CA-1996-01.html

CERT. 996b. CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoong Attacks. Available at:


CERT. 996c. CERT Advisory CA-1996-26: Denial-of-Service Attack via ping. Available at:


CERT. 997. CERT Advisory CA-1997-28: IP Denial-of-Service Attacks. Available at:


CERT 998a. CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks. Available at:http://www.cert.org/advisories/CA-1998-01.html



57


CERT. 998b. CERT Advisory CA-1998-13: Vulnerability in Certain TCP/IP Implementations. Available

at: http://www.cert.org/advisories/CA-1998-13.html

CERT. 999. CERT Advisory CA-1999-17: Denial-of-Service Tools. Available at:


CERT. 200. CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence

Numbers. Available at: http://www.cert.org/advisories/CA-2001-09.html

CERT. 2003. CERT Advisory CA-2003-15 Cisco IOS Interface Blocked by IPv4 Packet. Available at:


CIPSO. 992. COMMERCIAL IP SECURITY OPTION (CIPSO 2.2).IETFInternet-Draft(draft-ietf-cipso-

ipsecurity-01.txt).

CIPSOWG. 994. Commercial Internet Protocol Security Option (CIPSO) Working Group. WorkingGroup charter available at: http://www.ietf.org/proceedings/94jul/charters/cipso-charter.html

Cisco. 2003. Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 packet . Available at:

http://www.cisco.com/en/US/products/products_security_advisory09186a00801a34c2.shtml

Cisco. 2008. Cisco IOS Security Conguration Guide, Release 12.2. Available at:

http://www.cisco.com/en/US/docs/ios/12_2/security/conguration/guide/scpso.html

Clark,D.D.1982.IP datagram reassembly algorithms. RFC 85.

Clark,D.D.1988.The Design Philosophy of the DARPA Internet Protocols, Computer Communication

Review,Vol.18,No.4,pp.106-114.

daemon9,route,andinnity.1996. IP-spoong Demystied (Trust-Relationship Exploitation). Phrack

Magazine,VolumeSeven,IssueForty-Eight,File14of18.Availableat:http://www.phrack.org/

phrack/48/P48-14

Ed3f. 2002. Firewall spotting and networks analisys with a broken CRC.PhrackMagazine,Volume

0x0b,Issue0x3c,Phile#0x0cof0x10.Availableat:http://www.phrack.org/phrack/60/p60-0x0c.txt

Eddy,W.2007.TCP SYN Flooding Attacks and Common Mitigations. RFC 4987.

Ferguson,P.,andSenie,D.2000.Network Ingress Filtering: Defeating Denial of Service Attacks which

employ IP Source Address Spoong. RFC 2827.

FIPS. 994. Standard Security Label for Information Transfer. Federal Information Processing

Standards Publication. FIP PUBS 188. Available at: http://csrc.nist.gov/publications/ps/ps188/

ps188.pdf

Fuller,V.,Li,T.2006.ClasslessInter-domainRouting(CIDR):The Internet Assignment and

Aggregation Plan. RFC 4632.



58


Fuller,V.,Lear,E.,Meyer,D.2008.240.0.0.0/4:The Future Begins Now.RoutingSIGMeeting,25th

APNICOpenPolicyMeeting,February25–292008,Taipei,Taiwan.Slidesavailableat:http://www.

apnic.net/meetings/25/program/routing/fuller-240-future.pdf

Fuller,V.,Lear,E.,Meyer,D.2008.Reclassifying240/4 as usable unicast address space. IETFInternet-Draft(draft-fuller-240space-00.txt),workinprogress.

Fyodor,2004.Idle scanning and related IP ID games. Available at:

http://www.insecure.org/nmap/idlescan.html

GIAC. 2000. Egress Filtering v 0.2. Available at:

http://www.sans.org/y2k/egress.htm

Gill,V.,Heasley,J.,Meyer,D.,Savola,P.,Pignataro,C.2007.The Generalized TTL Security

Mechanism (GTSM). RFC 5082.

Gont,F.2006. Advanced ICMP packet ltering. Available at:

http://www.gont.com.ar/papers/icmp-ltering.html

Gont,F.2008.ICMP attacks against TCP ,IETFInternet-Draft(draft-ietf-tcpm-icmp-attacks-03.txt),

work in progress.

Graff,C.1995.IPv4 Option for Sender Directed Multi-Destination Delivery. RFC 770.

Haddad,I.,andZakrzewski,M.2004.Security Distribution for Linux Clusters.LinuxJournal.Available

at: http://www.linuxjournal.com/article/6943

Heffner,J.,Mathis,M.,andChandler,B.2006.IPv4Reassembly Errors at High Data Rates. RFC

4963.

Humble.1998.Nesteaexploit.Availableat:

http://www.insecure.org/sploits/linux.PalmOS.nestea.html

IANA. 2006a. Ether Types. Available at:

http://www.iana.org/assignments/ethernet-numbers

IANA. 2006b. IP Parameters. Available at:http://www.iana.org/assignments/ip-parameters

IANA. 2006c. Protocol Numbers. Available at:

http://www.iana.org/assignments/protocol-numbers

IRIX.2008.IRIX6.5trusted_networking(7)manualpage.Availableat:

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/

catman/a_man/cat7/trusted_networking.z



59


Jones,R.2002. A Method Of Selecting Values For the Parameters Controlling IP Fragment

Reassembly. Available at:

ftp://ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt

Katz,D.1997. IP Router Alert Option. RFC 23.

Kenney,M.1996.The Ping of Death Page. Available at:

http://www.insecure.org/sploits/ping-o-death.html

Kent,C.andMogul,J.1987.Fragmentation considered harmful .Proc.SIGCOMM‘87,Vol.17,No.5,

October 987.

Kent,S.1991.U.S. Department of Defense Security Options for the Internet Protocol. RFC 08.

Klein,A.2007.OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability.

Available at: http://www.trusteer.com/les/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_

Predictable_IP_ID_Vulnerability.pdf

Kohno,T.,Broido,A.,andClaffy,K.C.2005.Remote Physical Device Fingerprinting. IEEE

TransactionsonDependableandSecureComputing.IEEETransactionsonDependableandSecure

Computing,Vol.2,No.2.

LBNL/NRG.2006.arpwatchtool.Availableat:

http://ee.lbl.gov/

Linux.2006.TheLinuxKernel.Availableat: http://www.kernel.org

Malkin,G.1993.Traceroute Using an IP Option. RFC 393

Mathis,M.,andHeffner,J.2007.Packetization Layer Path MTU Discovery. RFC 482.

Microsoft. 999. Microsoft Security Program: Microsoft Security Bulletin (MS99-038). Patch Available

for “Spoofed Route Pointer” Vulnerability. Available at:

http://www.microsoft.com/technet/security/bulletin/ms99-038.mspx

Miller,I.2001.Protection Against a Variant of the Tiny Fragment Attack. RFC 328.

Mogul,J.,Kent,C.,Partridge,C.,McCloghrie,K.1988. IP MTU Discovery Options. RFC 063.

Mogul,J.,andDeering,S.1990.Path MTU Discovery. RFC 9.

Nichols,K.,Blake,S.,Baker,F.,andBlack,D.1998.Denition of the Differentiated Services Field (DS

Field) in the IPv4 and IPv6 Headers. RFC 2474.

NISCC. 2004. NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP. Available at:

http://www.uniras.gov.uk/niscc/docs/re-20040420-00391.pdf



60


NISCC. 2005. NISCC Vulnerability Advisory 532967/NISCC/ICMP: Vulnerability Issues in ICMP

packets with TCP payloads. Available at:

http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf

NISCC. 2006. NISCC Technical Note 01/2006: Egress and Ingress Filtering. Available at:http://www.niscc.gov.uk/niscc/docs/re-20060420-00294.pdf?lang=en

Northcutt,S.,andNovak,J.2000.Network Intrusion Detection – An Analyst’s Handbook. Second

Edition. New Riders Publishing.

Novak,J.2005.Target-Based Fragmentation Reassembly . Available at:

http://www.snort.org/reg/docs/target_based_frag.pdf

OpenBSD.1998.OpenBSD Security Advisory: IP Source Routing Problem. Available at:

http://www.openbsd.org/advisories/sourceroute.txt

Paxson,V.,Handley,M.,andKreibich,C.2001.Network Intrusion Detection: Evasion, Trafc

Normalization, and End-to-End Protocol Semantics.USENIXConference,2001.

Plummer,D.C.1982. An Ethernet Address Resolution Protocol. RFC 826.

Postel,J.1981.Internet Protocol. DARPA Internet Program. Protocol Specication. RFC 79.

Ptacek,T.H.,andNewsham,T.N.1998. Insertion, Evasion and Denial of Service: Eluding Network

Intrusion Detection. Secure Networks, Inc. Available at:

http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps

Ramakrishnan,K.,Floyd,S.,andBlack,D.2001.The Addition of Explicit Congestion Notication

(ECN) to IP. RFC 368.

Rekhter,Y.,Moskowitz,B.,Karrenberg,D.,deGroot,G.J.,andLear,E.1996. Address Allocation for

Private Internets. RFC 98.

Sanlippo,S.1998a. about the ip header id.PosttoBugtraqmailing-list,MonDec141998.Available

at: http://www.kyuzz.org/antirez/papers/ipid.html

Sanlippo,S.1998b. Idle scan.PosttoBugtraqmailing-list.Availableat: http://www.kyuzz.org/antirez/papers/dumbscan.html

Sanlippo,S.1999. more ip id.PosttoBugtraqmailing-list.Availableat:

http://www.kyuzz.org/antirez/papers/moreipid.html

Savola,P.2006.MTU and Fragmentation Issues with In-the-Network Tunneling. 2006. RFC 4459.

SELinux.2008.SecurityEnhancedLinux.

Availableat:http://www.nsa.gov/selinux/




Senie,D.1999.Changing the Default for Directed Broadcasts in Routers. RFC 2644.

Shankar,U.,andPaxson,V.2003. Active Mapping: Resisting NIDS EvasionWithout Altering Trafc.

Available at: http://www.icir.org/vern/papers/activemap-oak03.pdf

Shannon,C.,Moore,D.,andClaffy,K.C.2001.Characteristics of Fragmented IP Trafc on Internet

Links.

Shepler,S.,Callaghan,B,Robinson,D.,Thurlow,R.,Beame,C.,Eisler,M.,Noveck,D,2003.Network

File System (NFS) version 4 Protocol. RFC 3530.

Silbersack,M.J.2005.Improving TCP/IP security through randomization without sacricing

interoperability.EuroBSDCon2005Conference.Slidesavailableat:

http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf

Solaris. 2008. Solaris Trusted Extensions - Labeled Security for Absolute Protection. Available at:http://www.sun.com/software/solaris/ds/trusted_extensions.jsp#3

Song,D.1999.Frag router tool. Available at:

http://www.anzen.com/research/nidsbench/

St.Johns,M.1988.Draft Revised IP Security Option. RFC 038.

St.Johns,M.,Atkinson,R.,andThomas,G.2008.Common Architecture Label IPv6 Security Option

(CALIPSO).IETFInternet-Draft(draft-stjohns-sipso-03.txt),workinprogress.

Templin,F.2006.Requirements for IP-in-IP Tunnel MTU Assurance.IETFInternet-Draft(draft-templin-

mtuassurance-01.txt),workinprogress.

US-CERT.2001.US-CERT Vulnerability Note VU#446689: Check Point FireWall-1 allows fragmented

packets through rewall if Fast Mode is enabled. Available at:

http://www.kb.cert.org/vuls/id/446689

US-CERT.2002.US-CERT Vulnerability Note VU#310387: Cisco IOS discloses fragments of previous

packets when Express Forwarding is enabled. Available at:

http://www.kb.cert.org/vuls/id/310387

Watson,Paul.2004.Slipping in the Window: TCP Reset Attacks. CanSecWest 2004 Conference.

Wilson,P.,Michaelson,G.,Huston,G.2007.Redesignation of 240/4 from “Future Use” to “Limited

Use for Large Private Internets”.IETFInternet-Draft(draft-wilson-class-e-01.txt).

Zakrzewski M and Haddad I 2002 Linux Distributed Security Module Linux Journal Available at:

security assessment of the internet protocol

Documents