SECURITY ASSESSMENT

OF THE INTERNET PROTOCOL
july 2008
Written by Fernando Gont on behalf of CPNI.
Disclaimer
Reference to any specifc 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 profts or anticipated profts, 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 felds .............................................................................................. 7
3. Version ............................................................................................................................. 7
3.2 IHL (Internet Header Length) ............................................................................................ 8
3.3 TOS ................................................................................................................................. 8
3.4 Total Length ..................................................................................................................... 9
3.5Identifcation(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.2Issueswithspecifcoptions ....................................................................................... 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
Security Assessment of the Internet Protocol
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.6StreamIdentifer(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.14DifferentiatedServicesfeld .......................................................................................... 37
3.15ExplicitCongestionNotifcation(ECN) ......................................................................... 38

4. Internet Protocol Mechanisms ............................................................................................. 40
4. Fragment reassembly .................................................................................................... 40
4.. Problems related with memory allocation .................................................................... 4
4.1.2ProblemsthatarisefromthelengthoftheIPIdentifcationfeld ................................... 42
4.1.3Problemsthatarisefromthecomplexityofthereassemblyalgorithm ......................... 43
4..4 Problems that arise from the ambiguity of the reassembly process ............................. 43
4..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
Security Assessment of the Internet Protocol
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,manyprotocolspecifcationsfocusonlyontheoperationalaspectsoftheprotocols
they specify and overlook their security implications.
ThoughInternettechnologyhasevolved,thebuildingblocksarebasicallythesamecore
protocolsadoptedbytheARPANETmorethantwodecadesago.Duringthelasttwenty
yearsmanyvulnerabilitieshavebeenidentifedintheTCP/IPstacksofanumberof
systems.Somewerefawsinprotocolimplementationswhichaffectonlyareduced
numberofsystems.Otherswerefawsintheprotocolsthemselvesaffectingvirtuallyevery
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
offcialdocuments(RFCs)beingissuedbytheIETF(InternetEngineeringTaskForce)
leading to a situation in which “known” security problems have not always been
addressedbyallvendors.Inmanycasesvendorshaveimplementedquick“fxes”to
protocolfawswithoutacarefulanalysisoftheireffectivenessandtheirimpacton
interoperability[Silbersack,2005].
Asaresult,anysystembuiltinthefutureaccordingtotheoffcialTCP/IPspecifcations
mightreincarnatesecurityfawsthathavealreadyhitourcommunicationsystemsinthe
past.
ProducingasecureTCP/IPimplementationnowadaysisaverydiffculttaskpartly
because of no single document that can serve as a security roadmap for the protocols.
ThereisclearlyaneedforacompaniondocumenttotheIETFspecifcationsthat
discussesthesecurityaspectsandimplicationsoftheprotocols,identifesthepossible
threats,proposespossiblecounter-measures,andanalysestheirrespectiveeffectiveness.
4
Security Assessment of the Internet Protocol
ThisdocumentistheresultofanassessmentoftheIETFspecifcationsoftheInternet
Protocolfromasecuritypointofview.Possiblethreatswereidentifedand,where
possible,counter-measureswereproposed.Additionally,manyimplementationfawsthat
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 to
performingasecurityassessmentoftherelevantIETFspecifcationbutalsooffersan
assessment of common implementation strategies.

WhilstnotaimingtobethefnalwordonthesecurityoftheIP,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 as
accurate as possible and to keep it updated as new threats are discovered.
1.2 Scope of this document
WhilethereareanumberofprotocolsthataffectthewayinwhichIPsystemsoperate,
thisdocumentfocusesonlyonthespecifcationsoftheIP.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.ProtocolSpecifcation”(51
pages).
• RFC815,“IPdatagramreassemblyalgorithms”(9pages).
• RFC1122,“RequirementsforInternetHosts--CommunicationLayers”(116
pages).
• RFC1812,“RequirementsforIPVersion4Routers”(175pages).
• RFC2474,“DefnitionoftheDifferentiatedServicesField(DSField)intheIPv4and
IPv6 Headers” (20 pages).
• RFC2475,“AnArchitectureforDifferentiatedServices”(36pages).
• RFC3168,“TheAdditionofExplicitCongestionNotifcation(ECN)toIP”(63pages).
1.3 Organisation of this document
Thisdocumentisbasicallyorganisedintwoparts:“InternetProtocolheaderfelds”and
“InternetProtocolmechanisms”.Theformercontainsananalysisofeachofthefeldsof
theInternetProtocolheader,identifestheirsecurityimplications,anddiscussesthe
possiblecounter-measures.Thelattercontainsananalysisofthesecurityimplicationsof
the mechanisms implemented by the Internet Protocol.
5
Security Assessment of the Internet Protocol
1.4 Typographical conventions
ThroughoutthisdocumenttheheaderfeldsoftheInternetProtocolsarediscussedin
detail.Insomecases,agiventermmayhaveaslightlydifferentmeaningdependingon
whetheritisusedtorefertoaconceptortoaspecifcfeldoftheInternetProtocol
header.Toavoidanypossibleconfusionarisingfromthisambiguity,whenreferringtoa
specifcfeldoftheIPheaderthenameofthefeldiswritteninthisfont type.
Throughoutthedocumenttherearealsoanumberofparentheticalnotessuchasthisone,
toprovideadditionaldetailsorclarifcations.
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 (vulteam@cpni.gov.uk) 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,especiallywheretheymayhaveanimpactonCriticalNational
Infrastructure’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,Roque
Gagliano,GuillermoGont,MartinMarino,PekkaSavola,andChristosZoulasforproviding
valuable comments on earlier versions of this document.
TheauthorwouldliketothankRandallAtkinsonandRoqueGagliano,whogenerously
answered a number of questions.
Finally,theauthorwouldliketothankCPNIfortheircontinuedsupport.
6
Security Assessment of the Internet Protocol
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
Security Assessment of the Internet Protocol
3. Internet Protocol header felds
TheIETFspecifcationsoftheInternetProtocoldefnethesyntaxoftheprotocolheader,
alongwiththesemanticsofeachofitsfelds.Figure1showstheformatofanIP
datagram.

Figure : Internet Protocol header format

EvenwhentheminimumIPheadersizeis20bytes,anIPmodulemightbehandedan
(illegitimate)“datagram”oflessthan20bytes.Therefore,beforedoinganyprocessingof
theIPheaderfelds,thefollowingcheckshouldbeperformedbytheIPmoduleonthe
packetshandedbythelink-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-bitfeldthatindicatestheversionoftheIP,andthusthesyntaxofthepacket.
ForIPv4,thisfeldmustbe4.
Whenalink-layerprotocolde-multiplexesapackettoaninternetmodule,itdoesso
basedona“ProtocolType”feldinthedata-linkpacketheader.
Intheory,differentversionsofIPcouldcoexistonanetworkbyusingthesame“Protocol
Type”atthelink-layer,butadifferentvalueintheVersionfeldoftheIPheader.Thusa
singleIPmodulecouldhandleallversionsoftheInternetProtocol,differentiatingthemby
meansofthisfeld.
8
Security Assessment of the Internet Protocol
However,inpracticedifferentversionsofIPareidentifedbyadifferent“ProtocolType”
numberinthelink-layerprotocolheader.Forexample,IPv4datagramsareencapsulated
inEthernetframesusinga“ProtocolType”feldof0x0800,whileIPv6datagramsare
encapsulatedinEthernetframesusinga“ProtocolType”feldof0x86DD[IANA,2006a].
ThereforeifanIPv4modulereceivesapacket,theVersionfeldmustbecheckedtobe4.
If this check fails the packet should be silently dropped.
3.2 IHL (Internet Header Length)
TheIHL(InternetHeaderLength)indicatesthelengthoftheinternetheaderin32-bit
words(4bytes).Astheminimumdatagramsizeis20bytes,theminimumlegalvaluefor
thisfeldis5andthefollowingcheckshouldbeenforced:
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 feld,defnedbyRFC791[Postel,
1981],andupdatedbyRFC1349[Almquist,1992].

Figure2:TypeofServicefeld

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
Security Assessment of the Internet Protocol
Where:
Precedence
: Network Control
0: Internetwork
101: CRITIC/ECP
00: Flash Override
0: Flash
00: Immediate
00: Priority
000: Routine
The Type of Servicefeldcanbeusedtoaffectthewayinwhichthepacketistreatedby
thesystemsofanetworkthatprocessit.Section4.2.1(“Precedence-orderedqueue
service”) and Section 4.2.3 (“Weak TOS”) of this document describe the security
implications of the Type of Servicefeldintheforwardingofpackets.
3.4 Total Length
The Total Lengthfeldisthelengthofthedatagram,measuredinbytes,includingboth
theIPheaderandtheIPpayload.Beinga16-bitfeld,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
thanthevalueactuallycontainedintheTotalLengthfeld.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
feldoftheIPpacketitcontains.
0
Security Assessment of the Internet Protocol
The IP module could also be handled a packet that is smaller than the actual IP packet
size claimed by the Total Lengthfeld.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 LengthfeldoftheIPheader.
[US-CERT,2002]isanexampleoftheexploitationofaforgedIPTotal Lengthfeldto
produce an information leakage attack.
3.5 Identifcation (ID)
The Identifcationfeldissetbythesendinghosttoaidinthereassemblyoffragmented
datagrams.Atanytime,itneedstobeuniqueforeachsetof{Source Address,
Destination Address, Protocol}.
InmanysystemsthevalueusedforthisfeldisdeterminedattheIPlayeronaprotocol-
independent basis. Many of those systems also simply increment the IP Identifcation
feldforeachpackettheysend.
Thisimplementationstrategyisinappropriateforanumberofreasons.First,ifthe
Identifcationfeldissetonaprotocol-independentbasis,itwillwrapmoreoftenthan
necessary,andthustheimplementationwillbemorepronetotheproblemsdiscussedin
[KentandMogul,1987]and[Heffner,Mathis,andChandler,2006].
Secondly,thisimplementationstrategyopensthedoortoaninformationleakagethatcan
beexploitedtoinanumberofways.[Sanflippo,1998a]originallypointedouthowthis
feldcouldbeexaminedtodeterminethepacketrateatwhichagivensystemis
transmittinginformation.Later,[Sanflippo,1998b]describedhowasystemwithsuchan
implementation can be used to perform a stealth port scan to a third (victim) host.
[Sanflippo,1999]explainedhowtoexploitthisimplementationstrategytouncoverthe
rulesofanumberoffrewalls.[Bellovin,2002]explainshowtheIPIdentifcationfeldcan
beexploitedtocountthenumberofsystemsbehindaNAT.[Fyodor,2004]isanentire
paperonmost(ifnotall)thewaystoexploittheinformationprovidedbythe
IdentifcationfeldoftheIPheader.
3.5.1 Some workarounds implemented by the industry
As the IP Identifcationfeldisonlyusedforthereassemblyofdatagrams,
someoperatingsystems(suchasLinux)decidedtosetthisfeldto0inall
packetsthathavetheDFbitset.Thiswould,inprinciple,avoidanytypeof
informationleakage.However,itwasdetectedthatsomenon-RFC-compliant
middle-boxesfragmentedpacketseveniftheyhadtheDFbitset.Insucha
scenarioalldatagramsoriginallysentwiththeDFbitsetwouldresultin
fragments that would have an Identifcationfeldof0,whichwouldleadto
problems(“collision”oftheIdentifcationnumber)inthereassemblyprocess.

Security Assessment of the Internet Protocol
Linux(andSolaris)latersettheIPIdentifcationfeldonaper-IP-address
basis. This avoids some of the security implications of the IP Identifcation
feld,butnotall.Forexample,systemsbehindaloadbalancercanstillbe
counted.
3.5.2 Possible security improvements
Contrarytocommonwisdom,theIP Identifcationfelddoesnotneedtobe
system-wideuniqueforeachpacket,buthastobeuniqueforeach{Source
Address, Destination Address, Protocol} tuple.
Forinstance,theTCPspecifcationdefnesagenericsend()functionwhich
takestheIPIDasoneofitsarguments.
We provide an analysis of the possible security improvements that could be
implemented,basedonwhethertheprotocolusingtheservicesofIPis
connection-orientedorconnection-less.
Connection-oriented protocols
Toavoidthesecurityimplicationsoftheinformationleakagedescribedabove,
apseudo-randomnumbergenerator(PRNG)couldbeusedtosettheIP
Identifcationfeldona{Source Address, Destination Address} basis (for
eachconnection-orientedtransportprotocol).
[Klein,2007]isasecurityadvisorythatdescribesaweaknessinthepseudo
random number generator (PRNG) in use for the generation of the IP
Identifcation by a number of operating systems.
Whileintheoryapseudo-randomnumbergeneratorcouldleadtoscenarios
in which a given Identifcation 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
Identifcationfeldshouldbefrequentlyreusedandeitherstrongpacket
reordering or packet loss should take place.
Nevertheless,regardlessofwhatpolicyisusedforselectingthe
Identifcationfeld,withthecurrentlinkspeedsfragmentationisalreadybad
2
Security Assessment of the Internet Protocol
enough to rely on it. A mechanism for avoiding fragmentation should be
implemented instead.
Connectionless protocols
Connectionless protocols usually have these characteristics:
• lackoffow-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.
• Thedatatransferrateswillbelowenoughthatfowcontrolwillbe
unnecessary.
• Packet loss is not important and probably also unlikely.
Withtheseassumptionsinmind,theIdentifcationfeldcouldstillbeset
accordingtoapseudo-randomnumbergenerator(PRNG).Intheeventa
given Identifcationnumberwasreusedwhilethefrstinstanceofthesame
numberisstillonthenetwork,thefrstIPdatagramwouldbereassembled
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 Identifcation numbers).
InthecaseofUDP,unfortunatelysomesystemshavebeenknowntonot
enabletheUDPchecksumbydefault.Formostapplications,packets
containing errors should be dropped. Probably the only application that may
beneftfromdisablingthechecksumisstreamingmedia,toavoiddroppinga
completesampleforasingle-biterror.
Ingeneral,ifIPIdentifcation number collisions become an issue for the
applicationusingtheconnection-lessprotocol,thenuseofadifferent
transport protocol (which hopefully avoids fragmentation) should be
considered.
AnattackercouldintentionallyexploitcollisionsofIPIdentifcation numbers
toperformaDenialofServiceattackbysendingforgedfragmentsthatwould
causethereassemblyprocesstoresultinacorruptdatagram,thatwould
3
Security Assessment of the Internet Protocol
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
4
Security Assessment of the Internet Protocol
InFigure3,anattackersendsa17914-bytedatagrammeanttothevictimhost.The
attacker’s packet probably contains an overlapping IP fragment or an overlapping TCP
segment,aimingat“confusing”theNIDS,asdescribedin[PtacekandNewsham,1998].
ThepacketisscreenedbytheNIDSsensoratthenetworkperimeter,whichprobably
reassembles IP fragments and TCP segments for the purpose of assessing the data
transferred to and from the monitored systems. However as the attacker’s packet should
transitalinkwithanMTUsmallerthan17914bytes(1500bytesinthisexample),the
router that encounters that this packet cannot be forwarded without fragmentation
(RouterB)discardsthepacket,andsendsanICMP“fragmentationneededandDFbit
set”errormessagetothesourcehost.InthisscenariotheNIDSmayremainunawarethat
thescreenedpacketneverreachedtheintendeddestination,andthusgetanincorrect
picture of the data being transferred to the monitored systems.
[ShankarandPaxson,2003]introducesatechniquenamed“ActiveMapping”thatprevents
evasionofaNIDSbyacquiringsuffcientknowledgeaboutthenetworkbeingmonitored,to
assesswhichpacketswillarriveattheintendedrecipient,andhowtheywillbeinterpreted
by it
SomefrewallsareknowntodroppacketsthathaveboththeMF (More Fragments) and
the DF(Don’tfragment)bitsset.Whilesuchapacketmightseemnonsensical,therearea
numberofreasonswhynon-maliciouspacketswiththesetwobitssetcanbefoundina
network.First,theymayexistastheresultofsomemiddle-boxprocessingapacketthat
was too large to be forwarded without fragmentation. Instead of simply dropping the
correspondingpacketandsendinganICMPerrormessagetothesourcehost,some
middle-boxesfragmentthepacket(copyingtheDF bit to each fragment) and also send
anICMPerrormessagetotheoriginatingsystem.Second,somesystems(notablyLinux)
set both the MF and the DFbitstoimplementPath-MTUDiscovery(PMTUD)forUDP.
Thesescenariosshouldbetakenintoaccountwhenconfguringfrewallsand/ortuning
NetworkIntrusionDetectionSystems(NIDS).
3.7 Fragment Offset
The Fragment Offset is used for the fragmentation and reassembly of IP datagrams. It
indicates where in the original datagram the fragment belongs and is measured in units of
eightbytes.Asaconsequenceallfragments(exceptthelastone)havetobealignedon
an8-byteboundary.ThereforeifapackethastheMFfagsetthefollowingcheckshould
be enforced:
(Total Length – IHL * 4) % 8 == 0
If the packet does not pass this check it should be dropped.
Given that Fragment Offsetisa13-bitfelditcanholdavalueofupto8191which
wouldcorrespondtoanoffset65528byteswithintheoriginal(non-fragmented)datagram.
Assuch,itispossibleforafragmenttoimplicitlyclaimtobelongtoadatagramlargerthan
65535bytes(themaximumsizeforalegitimateIPdatagram).Evenwhenthe
fragmentation mechanism would seem to allow fragments that could reassemble into
largedatagrams,theintentofthespecifcationistoallowforthetransmissionof
5
Security Assessment of the Internet Protocol
datagramsofupto65535bytes.Therefore,ifagivenfragmentwouldreassembleintoa
datagramofmorethan65535bytes,theresultingdatagramshouldbedropped.To
detectsuchacase,thefollowingcheckshouldbeenforcedonallpacketsforwhichthe
Fragment Offsetcontainsanon-zerovalue:
Fragment Offset * 8 + (Total Length – IHL * 4) <= 65535
Intheworst-casescenario,thereassembleddatagramcouldhaveasizeofupto131043
bytes.
SuchadatagramwouldresultwhenthefrstfragmenthasaFragment 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,soastoavoidthemfromoverfowingthebuffer(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)feldhastwofunctions:tobindthelifetimeoftheupper-layer
packets(e.g.TCPsegments)andtopreventpacketsfromloopingindefnitelyinthe
network.
Originally,thisfeldwasmeanttoindicatemaximumtimeadatagramwasallowedto
remain within the internet system in units of seconds. As every internet module that
processes a datagram must decrement the TTLbyatleastone,theoriginaldefnitionof
the TTLfeldbecameobsolete,anditmustnowbeinterpretedasahopcount.
MostsystemsallowtheadministratortoconfguretheTTLtobeusedforthepacketssent
with the default value usually being a power of 2. The recommended value for the TTL
feld,asspecifedbytheIANAis64[IANA,2006b].Thisvaluerefectstheassumed
“diameter” of the Internet plus a margin to accommodate its growth.
The TTLfeldhasanumberofpropertiesthatareinterestingfromasecuritypointofview.
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-boxthatoverwritestheTTLfeldinanon-standardway,betweentheoriginating
system and the point of the network in which the packet was received.
6
Security Assessment of the Internet Protocol
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
responsesfromthedevicesbeingfngerprintedandeachresponsethatarriveswitha
different TTL could be assumed to come from a different device.
Ofcourse,thereareothermoreprecisetechniquestofngerprintphysicaldevices.Amongst
thedrawbacksofthismethod,whilemanysystemsdifferinthedefaultTTL they use for the
packetstheysend,therearealsomanyimplementationswhichusethesamedefaultTTL.
Additionally,packetssentbyagivendevicemaytakedifferentroutes(e.g.duetoload
sharing or route changes) and thus a given packet may incorrectly be presumed to come
from a different device when in fact it just traveled a different route.
Locating the source host in the network topology
The TTLfeldmayalsobeusedtolocatethesourcesysteminthenetworktopology
[NorthcuttandNovak,2000].

7
Security Assessment of the Internet Protocol
Figure4:TrackingahostbymeansoftheTTLfeld
ConsidernetworktopologyofFigure4.Assumingthatanattacker(“F”inthefgure)is
performing an attack that requires forging the Source Address(suchasaTCP-based
DoSrefectionattack),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,theonlysystemthatsatisfesalltheseconditionsisthe
one marked as the “F”.
Thescenariodescribedaboveisforillustrationpurposesonly.Inpractice,therearea
number of factors that may prevent this technique from being successfully applied:
8
Security Assessment of the Internet Protocol
• 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 TTLfeldcanbeusedtoevadeNetworkIntrusionDetectionSystems.Dependingon
thepositionofasensorrelativetothedestinationhostoftheexaminedpacket,theNIDS
maygetadifferentpicturefromthatoftheintendeddestinationsystem.Asanexample,a
sensormayprocessapacketthatwillexpirebeforegettingtothedestinationhost.A
generalcounter-measureforthistypeofattackistonormalisethetraffcthatgetstoan
organisationalnetwork.Examplesofsuchtraffcnormalisationcanbefoundin[Paxsonet
al,2001].
Improving the security of applications that make use of the Internet
Protocol (IP)
In some scenarios the TTLfeldcanbealsousedtoimprovethesecurityofanapplication
byrestrictingthehoststhatcancommunicatewiththegivenapplication.Forexample,
there are applications for which the communicating systems are typically in the same
networksegment(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 TTLfeldcansimilarlybeusedinscenariosinwhichthecooperatingsystemseither
do not use a default TTLof255,orarenotinthesamenetworksegment(i.e.,multi-hop
peering).Inthatcase,thefollowingcheckcouldbeenforced:
TTL>=255-Δhops
9
Security Assessment of the Internet Protocol
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 TTLfeldforprotectingmulti-hoppeeringstillreducesthesetofhoststhat
could potentially perform a number of attacks against the protected application.
This use of the TTLfeldhasbeenoffciallydocumentedbytheIETFunderthename
“GeneralisedTTLSecurityMechanism”(GTSM)in[Gilletal,2007].
Some protocol scrubbers enforce a minimum value for the TTLfeldofthepacketsthey
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 Protocolfeldindicatestheprotocolencapsulatedintheinternetdatagram.The
Protocolfeldmaynotonlycontainavaluecorrespondingtoanimplementedprotocol
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
protocolfeld,therehavebeensecurityissuesinthepastwithsystemsthathadproblems
whenhandlingpacketswithsomespecifcprotocolnumbers[Cisco,2003][CERT,2003].
3.10 Header Checksum
The Header Checksumfeldisanerrordetectionmechanismmeanttodetecterrorsin
the IP header. While in principle there should not be security implications arising from this
feld,itshouldbenotedthatduetonon-RFC-compliantimplementations,theHeader
Checksummightbeexploitedtodetectfrewallsand/orevadenetworkintrusion
detectionsystems(NIDS).
[Ed3f,2002]describestheexploitationoftheTCPchecksumforperformingsuchactions.
As there are internet routers known to not check the IP Header Checksum,andthere
mightalsobemiddle-boxes(NATs,frewalls,etc.)notcheckingtheIPchecksumallegedly
duetoperformancereasons,similarmaliciousactivitytotheonedescribedin[Ed3f,2002]
might be performed with the IP checksum.
3.11 Source Address
The Source AddressofanIPdatagramidentifesthenodefromwhichthepacket
originated.
Strictlyspeaking,theSource AddressofanIPdatagramidentifestheinterfaceofthe
sendingsystemfromwhichthepacketwassent,(ratherthantheoriginating“system”),asin
the Internet Architecture there’s no concept of “node”.
20
Security Assessment of the Internet Protocol
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/egressflteringintheinternetrouters.[NISCC,
2006]isadetailedguideoningressandegressfltering.[BakerandSavola,2004]and
[FergusonandSenie,2000]discussingressfltering.[GIAC,2000]discussesegress
fltering.
Evenwhentheobviousfeldonwhichtoperformchecksforingress/egressflteringisthe
Source Address and Destination AddressfeldsoftheIPheader,thereareother
occurrences of IP addresses on which the same type of checks should be performed. One
exampleistheIPaddressescontainedinthepayloadofICMPerrormessages,as
discussedin[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 AddressofanIPdatagramidentifesthedestinationhosttowhichthe
packet is meant to be delivered.
Strictlyspeaking,theDestination AddressofanIPdatagramidentifestheinterfaceof
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
Security Assessment of the Internet Protocol
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-typehasthreefelds:
• bit: copied fag.
• 2 bits: option class.
• 5 bits: option number.
The copied fag 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 numberidentifesthesyntaxoftherestoftheoption.
3.13.1 General issues with IP options
The following subsections discuss security issues that apply to all IP options.
Theproposedchecksshouldbeperformedinadditiontoanyoption-specifc
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.
• Enforcealimitonthemaximumnumberofoptionstobeacceptedona
given internet datagram.
22
Security Assessment of the Internet Protocol
ThefrstcheckavoidsafowofpacketswithIPoptionstooverwhelmthe
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
potentialsecurityproblemsincludingbufferoverfows.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
becauseofainvalidvalueinafeld,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 protocol
felds.
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
protocolfeld(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
protocolfeldisencountered.
Option length
Section3.2.1.8ofRFC1122explicitlystatesthattheIPlayermustnotcrash
astheresultofanoptionlengththatisoutsidethepossiblerange,and
mentions that erroneous option lengths have been observed to put some IP
implementationsintoinfniteloops.
Foroptionsthatbelongtothe“Case2”describedintheprevioussection,the
following check should be performed:
23
Security Assessment of the Internet Protocol
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-offsetistheoffsetofthefrstbyteoftheoptionwithintheIP
header,withthefrstbyteoftheIPheaderbeingassignedanoffsetof0.
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),asitwouldallowthegenerationofoverfows.
Data types
ManyIPoptionsusepointerandlengthfelds.Caremustbetakenastothe
datatypeusedforthesefeldsintheimplementation.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 specifc 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
Security Assessment of the Internet Protocol
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:
• Bypassfrewallrules
• 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
LSRRoptioncanbeusedasanamplifcationmethodforbandwidth-
exhaustionattacksasanattackercouldmakeapacketbouncemultipletimes
between a number of systems by carefully crafting an LSRR option.
ThisistheIPv4-versionoftheIPv6amplifcationattackthatwaswidely
publicisedin2007[BiondiandEbalard,2007].Theonlydifferenceisthatthe
maximumlengthoftheIPv4header(andhencetheLSRRoption)limitsthe
amplifcationfactorwhencomparedtotheIPv6counter-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
Security Assessment of the Internet Protocol
[OpenBSD,1998]isasecurityadvisoryaboutanimproperimplementationof
suchasystem-widetogglein4.4BSDkernels.
Section3.3.5ofRFC1122[Braden,1989]statesthatahostmaybeableto
actasanintermediatehopinasourceroute,forwardingasource-routed
datagramtothenextspecifedhop.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.
AsmanyotherIPoptionstheLSSRcontainsaLengthfeldthatindicatesthe
lengthoftheoption.GiventheformatoftheoptiontheLengthfeldshouldbe
checked to be at least 3 (three):
LSRR.Length>=3
If the packet does not pass this check it should be dropped.
Additionally,thefollowingcheckshouldbeperformedontheLengthfeld:
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
Pointerfeldshouldbeamultipleof4.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
Security Assessment of the Internet Protocol
LSRR.Pointer >LSRR.Length
In that case routing should be based on the Destination Addressfeldand
no further processing should be done on the LSRR option.
[Microsoft,1999]isasecurityadvisoryaboutavulnerabilityarisingfrom
improper validation of the LSRR.Pointerfeld.
If the address in the Destination Addressfeldhasbeenreached,andthe
optionisnotempty,thenextaddressinthesourceroutereplacestheaddress
in the Destination Addressfeld.
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,eachofthefragmentswillhavetogothrough
thelistofsystemsspecifedintheLSRRoption.
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
SSRRtheroutespecifedintheoptionistheexactroutethepacketmusttake
(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
Security Assessment of the Internet Protocol
• Bypassfrewallrules
• 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
SSRRoptioncanbeusedasanamplifcationmethodforbandwidth-
exhaustionattacksasanattackercouldmakeapacketbouncemultipletimes
between a number of systems by carefully crafting an LSRR option.
ThisistheIPv4-versionoftheIPv6amplifcationattackthatwaswidely
publicisedin2007[BiondiandEbalard,2007].Theonlydifferenceisthatthe
maximumlengthfortheIPv4header(andhencetheSSRRoption)limitsthe
amplifcationfactorwhencomparedtotheIPv6counter-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 Lengthfeldthat
indicatesthelengthoftheoption.Thelengthfeldshouldbecheckedtobeat
least 3:
SSRR.Length>=3
28
Security Assessment of the Internet Protocol
If the packet does not pass this check it should be dropped.
Additionally,thefollowingcheckshouldbeperformedonthelengthfeld:
SSRR.Offset + SSRR.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 Pointerfeldisrelativetothisoption,withtheminimumlegalvaluebeing
4 and so the following check should be performed:
SSRR.Pointer>=4
If the packet does not pass this check it should be dropped.
Additionally,thePointerfeldshouldbeamultipleof4.Consequently,the
following check should be performed:
SSRR.Pointer % 4 == 0
If a packet does not pass this check it should be dropped.
If the packet passes the above checks the receiving system should determine
whether the Destination Address of the packet corresponds to one of its IP
addresses.Ifdoesnot,itshouldbedropped.
ContrarytotheIPLooseSourceandRecordRoute(LSRR)option,theSSRR
option does not allow in the route other routers than those contained in the
option.Ifthesystemimplementstheweakend-systemmodelitisallowedfor
the system to receive a packet destined to any of its IP addresses on any of its
interfaces.Ifthesystemimplementsthestrongend-systemmodelapacket
destined to it can be received only on the interface that corresponds to the IP
address contained in the Destination Addressfeld[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,iftheaddressinthedestinationfeldhasnotbeenreachedthe
packet should be dropped.
[Microsoft,1999]isasecurityadvisoryaboutavulnerabilityarisingfrom
improper validation of the SSRR.Pointerfeld.
Iftheoptionisnotempty,andtheaddressintheDestination Address feld
hasbeenreached,thenextaddressinthesourceroutereplacestheaddress
29
Security Assessment of the Internet Protocol
in the Destination Addressfeld.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 the
IP 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
togothroughthelistofsystemsspecifedintheSSRRoption.
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,indicatingthefrstbyteoftheareain
whichtostorethenextroutedata.Thepointerisrelativetotheoptionstart.
RFC791statesthatthisoptionshouldappearonce,atmost,inagiven
packet.Therefore,ifapackethasmorethanoneinstanceofthisoptionit
should be dropped.
Giventheformatoftheoption,theLengthfeldshouldbecheckedtobeat
least 3:
RR.Length>=3
If the packet does not pass this check it should be dropped.
Additionally,thefollowingcheckshouldbeperformedontheLengthfeld:
RR.Offset + RR_Length < IHL *4

30
Security Assessment of the Internet Protocol
ThischeckassuresthattheoptiondoesnotoverlapwiththeIPpayload(i.e.,
it does not go past the IP header). If the packet does not pass this check it
should be dropped.
Thepointerfeldisrelativetothisoption,withtheminimumlegalvaluebeing
4. 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 feldshouldbeamultipleof4.Consequently,the
following check should be performed:
RR.Pointer % 4 == 0
If the packet does not pass this check it should be dropped.
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,thefollowingcheckshouldbeperformed
before 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 scenario
will 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.
Thisoptionisnotcopiedonfragmentationandappearsinthefrstfragment
only. If a fragment other than the one with offset 0 contains the Record Route
option it should be dropped.
3
Security Assessment of the Internet Protocol
TheRecordRouteoptioncanbeexploitedtolearnaboutthetopologyofa
network,asitallowsanattackertorecord.
3.13.2.6 Stream Identifer (Type = 136)
TheStreamIdentiferoptionoriginallyprovidedameansforthe16-bitSATNET
streamIdentifertobecarriedthroughnetworksthatdidnotsupportthe
stream concept.
However,asstatedbySection4.2.2.1ofRFC1812[Baker,1995],thisoption
is obsolete. Therefore it should be ignored by the processing systems.
Inthecaseoflegacysystemsstillusingthisoption,thelengthfeldofthe
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 that
processthepacket,whichtheattackermayfndusefulinanumberof
scenarios.
• Itmaybeusedtomapthenetworktopology,inasimilarwaytotheIP
Record Route option.
• Itmaybeusedtofngerprinttheoperatingsysteminusebyasystem
processing the datagram.
• Itmaybeusedtofngerprintphysicaldevices,byanalysingtheclock
skew.
Therefore,bydefault,thetimestampoptionshouldbeignored.
Forthosesystemsthathavebeenexplicitlyconfguredtohonorthisoption,
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 overfow/fag 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 the
following check should be performed:
32
Security Assessment of the Internet Protocol
IT.Length>=4
If the packet does not pass this check it should be dropped.
Thefollowingcheckshouldalsobeperformedontheoptionlengthfeld:
IT.Offset + IT.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 pointerbytepointstothefrstbyteoftheareainwhichthenext
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 Timestamp
option:
IT.Pointer >=5
If the packet does not pass this check it should be dropped.
The fag feldhasthreepossiblelegalvalues:
• 0:Recordtimestampsonly,storedinconsecutive32-bitwords.
• : Record each timestamp preceded with the internet address of the
registering entity.
• 3:Theinternetaddressfeldsoftheoptionarepre-specifed.AnIP
module only registers its timestamp if it matches its own address with
thenextspecifedinternetaddress.
Therefore the following check should be performed:
IT.Flag == 0 || IT.Flag == || IT.Flag == 3
If the packet does not pass this check it should be dropped.
The timestampfeldisaright-justifed32-bittimestampinmillisecondssince
UT.Ifthetimeisnotavailableinmilliseconds,orcannotbeprovidedwith
respecttoUT,thenanytimemaybeinsertedasatimestamp,providedthe
highorderbitofthetimestampisset,toindicatethisnon-standardvalue.
AccordingtoRFC791,theinitialcontentsofthetimestampareamustbe
initialisedtozero,orinternetaddress/zeropairs.However,internetsystems
shouldbeabletohandlenon-zerovaluespossiblydiscardingtheoffending
datagram.
33
Security Assessment of the Internet Protocol
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,theoverfowbyteshouldbeincremented,
and the packet should be forwarded without inserting the timestamp. If the
overfowbyteitselfoverfowsthepacketshouldbedropped.
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.

• Ifthefagbyteis3thenthefollowingcheckshouldbeperformed:
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
Security Assessment of the Internet Protocol
[Kohnoetal,2005]describesatechniqueforfngerprintingdevicesby
measuringtheclockskew.Itexploits,amongotherthings,thetimestamps
that can be obtained by means of the ICMP timestamp request messages
[Postel,1981].Thesamefngerprintingmethodcouldbeimplementedwith
the aid of the Internet Timestamp option.
3.13.2.8 Router Alert (Type = 148)
TheRouterAlertoptionisdefnedinRFC2113[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.
AccordingtothesyntaxoftheoptionasdefnedinRFC2113,thefollowing
check should be enforced:
RA.Length == 4
Ifthepacketdoesnotpassthischeckitshouldbedropped.Furthermore,the
following check should be performed on the Valuefeld:
RA.Value == 0
If the packet does not pass this check it should be dropped.
AsexplainedinRFC2113hostsshouldignorethisoption.
3.13.2.9 Probe MTU (Type =11)
ThisoptionisdefnedinRFC1063[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)
ThisoptionisdefnedinRFC1063[Moguletal,1988]andoriginallyprovided
amechanismtodiscoverthePath-MTU.
This option is obsolete and therefore any packet that is received containing
this option should be dropped.

35
Security Assessment of the Internet Protocol
3.13.2.11 Traceroute (Type = 82)
ThisoptionisdefnedinRFC1393[Malkin,1993],andoriginallyprovideda
mechanism to trace the path to a host.
Thisoptionisobsolete,andthereforeanypacketthatisreceivedcontaining
this option should be dropped.
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 autho rities indicated on the datagram.
ItisspecifedbyRFC1108[Kent,1991](whichobsoletesRFC1038[St.
Johns,1988]).
RFC791[Postel,1981]defnedthe“SecurityOption”(Type=130),which
usedthesameoptiontypeastheDoDBasicSecurityoptiondiscussedinthis
section.The“SecurityOption”specifedinRFC791isconsideredobsoleteby
Section4.2.2.1ofRFC1812,andthereforethediscussioninthissectionis
focusedontheDoDBasicSecurityoptionspecifedbyRFC1108[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
If the packet does not pass this check it should be dropped.
36
Security Assessment of the Internet Protocol
Systems that belong to networks in which this option is in use should process
theDoDBasicSecurityoptioncontainedineachpacketasspecifedin[Kent,
1991].
CurrentdeploymentsoftheDoDSecurityOptionshavemotivatedtheproposal
of a “Common Architecture Label IPv6 Security Option (CALIPSO)” for the IPv6
protocol.[St.Johnsetal,2008].
3.13.2.13 DoD Extended Security Option (Type = 133)
Thisoptionpermitsadditionalsecuritylabelinginformation,beyondthat
presentintheBasicSecurityOption(Section3.13.2.12),tobesuppliedinan
IPdatagramtomeettheneedsofregisteredauthorities.ItisspecifedbyRFC
1108[Kent,1991].
ThisoptionmaybepresentonlyinconjunctionwiththeDoDBasicSecurity
option.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
If the packet does not pass this check it should be dropped.
Systems that belong to networks in which this option is in use should process
theDoDExtendedSecurityoptioncontainedineachpacketasspecifedin
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.Itisspecifedin[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 Standard
Publication188”[FIPS,1994].
Itiscurrentlyimplementedinanumberofoperatingsystems(e.g.IRIX[IRIX,
2008],Security-EnhancedLinux[SELinux,2008],andSolaris[Solaris,2008])
anddeployedinanumberofhigh-securitynetworks.
37
Security Assessment of the Internet Protocol
[ZakrzewskiandHaddad,2002]and[HaddadandZakrzewski,2004]provide
anoverviewofaLinuximplementation.
Accordingtotheoptionsyntaxspecifedin[CIPSO,1992]thefollowing
validation check should be performed:
CIPSO.Length>=6
If a packet does not pass this check it should be dropped.
Systems that belong to networks in which this option is in use should process
theCIPSOoptioncontainedineachpacketasspecifedin[CIPSO,1992].
3.13.2.15 Sender Directed Multi-Destination Delivery (Type = 149)
ThisoptionisdefnedinRFC1770[Graff,1995],andoriginallyprovided
unreliableUDPdeliverytoasetofaddressesincludedintheoption.
This option is obsolete. If a received packet contains this option it should be
dropped.
3.14 Differentiated Services feld
TheDifferentiatedServicesArchitectureisintendedtoenablescalableservice
discriminationintheInternetwithouttheneedforper-fowstateandsignalingateveryhop
[Blakeetal,1998].RFC2474[Nicholsetal,1998]defnesaDifferentiated Services
Field (DSField),whichisintendedtosupersedetheoriginalType of Servicefeld.Figure
4showstheformatofthefeld.

Figure5:StructureoftheDSField
The DSCP (“Differentiated Services CodePoint”) is used to select the treatment the
packetistoreceivewithintheDifferentiatedServicesDomain.TheCU (“Currently
Unused”)feldwas,atthetimethespecifcationwasissued,reservedforfutureuse.The
DSCPfeldisusedtoselectaPHBbymatchingagainsttheentire6-bitfeld.
Considering that the DSCPfelddetermineshowapacketistreatedwithinaDSdomain,
an attacker sends packets with a forged DSCPfeldtoperformatheftofserviceoreven
38
Security Assessment of the Internet Protocol
aDenialofServiceattack.Inparticular,anattackercouldforgepacketswithacodepoint
ofthetype‘11x000’which,accordingtoSection4.2.2.2ofRFC2474[Nicholsetal,
1998],wouldgivethepacketspreferentialforwardingtreatmentwhencomparedwiththe
PHBselectedbythecodepoint‘000000’.Ifstrictpriorityqueuingwereutilised,a
continuousstreamofsuchpocketscouldperformaDenialofServicetootherfowswhich
have a DSCP of lower relative order.
As the DSfeldisincompatiblewiththeoriginalType of Servicefeld,bothDSdomains
and networks using the original Type of Servicefeldshouldprotectthemselvesbyre-
markingthecorrespondingfeldwhereappropriate,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 Notifcation (ECN)
RFC3168[Ramakrishnanetal,2001]specifesamechanismforrouterstosignal
congestiontohostssendingIPpacketsbymarkingtheoffendingpackets,ratherthan
discardingthem.RFC3168defnestheECNfeldwhichutilisestheCUunusedfeldof
the DSCPfelddescribedinSection3.14ofthisdocument.Figure5showsthesyntaxof
the ECNfeld,togetherwiththeDSCPfeldusedforDifferentiatedServices.

Figure6:TheDifferentiatedServicesandECNfeldsinIP
Assuch,theECNfelddefnesfourcodepoints:
ECN feld 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.OfthepossiblethreatsdiscussedintheECNspecifcationwebelievethatonethat
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
Security Assessment of the Internet Protocol
REDwouldmarkthepackets(withtheCEcodepoint)ratherthandiscardthem.Inthe
samescenario,packetsofcompetingfowsthatdonothavetheECTcodepointset
would be dropped. Therefore an attacker would get better network service than the
competingfows.
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
Security Assessment of the Internet Protocol
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),bypassingfrewallrules,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
exampleoftheexploitationofIPfragmentationtobypassfrewallrules.[CERT,1999]
describestheimplementationoffragmentationattacksinDistributedDenialofService
(DDoS)attacktools.
ThebasicproblemwithIPfragmentreassemblyisthecomplexityofthefunctionina
number of aspects:
• Fragment reassembly is a stateful operation for a stateless protocol (IP). The IP
module 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,asdescribedbytheIETFspecifcationsis
ambiguousandallowsforanumberofinterpretations,eachofwhichhasfound
placeindifferentTCP/IPstackimplementations.
• Thereassemblyprocessissomewhatcomplex.Fragmentsmayarriveoutoforder,
duplicated,overlapping,etc.andthiscomplexityhasleadtonumerousbugsin
different implementations of the IP protocol.
4
Security Assessment of the Internet Protocol
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
specifcationsrecommendtowaitforaperiodoftimethatwillbeacceptable
for virtually all the possible network scenarios in which the protocols might
operate.Specifcally,RFC1122[Braden,1989]statesthatthereassembly
timeoutshouldbeafxedvaluebetween60and120seconds.Ifafterwaiting
forthatperiodoftimetheremainingfragmentshavenotyetarrived,allthe
received fragments for the corresponding packet are discarded.
TheoriginalIPSpecifcation,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.25
minutes,withminimumof15seconds.Section3.3.2(“Reassembly”)ofRFC
1122correctedthisadvice,statingthatthereassemblytimeoutshouldbea
fxedvaluebetween60and120seconds.
However,thelongerthesystemwaitsforthemissingfragmentstoarrive,the
longer the corresponding system resources must be tied to the corresponding
packet.Theamountofsystemmemoryisfniteandevenwithtoday’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 will
neverreassembleintoacompletedatagram.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
Security Assessment of the Internet Protocol
Whilethismightbebenefcialinlegitimatecases,thisjustamplifestheimpact
ofthepossibleattacks,asasinglesmallfragmentcouldtieupmemory
buffersforthesizeofanextremelylarge(andunlikely)datagram.The
implementationstrategysuggestedinRFC815[Clark,1982]leadstosuchan
implementation.
The impact of the aforementioned attack may vary depending on some
specifcimplementationdetails:
• 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 all
further 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 Identifcation feld
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 Identifcationfeldisa16-bitfeldthatisusedforthefragmentationand
reassemblyfunction.Intheeventadatagramgetsfragmented,allthe
corresponding fragments will share the same Identifcationnumber.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 time
there must be at most only one packet in the network with a given
Identifcationnumber.Ifnot,anIdentifcation number “collision” might
occurandthereceivingsystemmightendup“mixing”fragmentsthat
correspond to different IP datagrams which simply reused the same
Identifcation number.
For each group of fragments whose Identifcation 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
Security Assessment of the Internet Protocol
Anattackercouldexploitthisfacttointentionallycauseasystemtodiscardall
orpartofthefragmentedtraffcitgets,thusperformingaDenialofService
attack.Suchanattackerwouldsimplyestablishafowoffragmentswith
differentIPIdentifcationnumberstotrashallorpartoftheIPIdentifcation
space.Asaresult,thereceivingsystemwouldusetheattacker’sfragments
forthereassemblyoflegitimatedatagrams,leadingtocorruptedpackets
which would later (and hopefully) get dropped.
Inmostcases,useofalongfragmenttimeoutwillbenefttheattackeras
forgedfragmentswillkeeptheIPIdentifcationspacetrashedforalonger
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
implementationbeingnotspecifcallytrivial.
[Shannonetal,2001]analysesthecausesandattributesoffragmenttraffc
measured in several types of WANs.
Duringtheyears,anumberofattackshaveexploitedbugsinthereassembly
functionofanumberofoperatingsystems,producingbufferoverfowsthat
haveled,inmostcases,toacrashoftheattackedsystem.
4.1.4 Problems that arise from the ambiguity of the reassembly
process
NetworkIntrusionDetectionSystems(NIDSs)typicallymonitorthetraffcona
givennetworkwiththeintentofidentifyingtraffcpatternsthatmightindicate
network intrusions.
InthepresenceofIPfragments,inordertodetectillegitimateactivityatthe
transportorapplicationlayers(i.e.,anyprotocollayerabovethenetwork
layer),aNIDSmustperformIPfragmentreassembly.
Inordertocorrectlyassessthetraffc,theresultofthereassemblyfunction
performedbytheNIDSshouldbethesameasthereassemblyfunction
performed by the intended recipient of the packets.
However a number of factors make the result of the reassembly process
ambiguous:
• TheIETFspecifcationsareambiguousastowhatshouldbedone
44
Security Assessment of the Internet Protocol
whenoverlappingfragmentswerereceived.Thus,inthepresenceof
overlappingdata,thesystemperformingthereassemblyfunctionisfree
toeitherhonorthefrstsetofdatareceived,thelatestcopyreceived,or
any other copy received in between.
• Asthespecifcationsdonotenforceanyspecifcfragmenttimeout
value,differentsystemsmaychoosedifferentvaluesforthefragment
timeout. This means that given a set of fragments received at some
specifedtimeintervalssomesystemswillreassemblethefragments
into a full datagram while others may timeout the fragments and
therefore drop them.
• AsthefragmentbuffersgetfullaDenialofService(DoS)conditionwill
occurunlesssomeactionistaken.Manysystemsfushpartofthe
fragmentbufferswhensomethresholdisreached.Thus,dependingon
fragmentload,timingissuesandfushingpolicy,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
Oneapproachtofragmentflteringinvolveskeepingtrackoftheresultsof
applyingflterrulestothefrstfragment(i.e.aFragment Offset of 0) and
applyingthemtosubsequentfragmentsofthesamepacket.Thefltering
modulewouldmaintainalistofpacketsindexedbytheSource Address,
Destination Address,ProtocolandIdentifcationnumber.Whentheinitial
fragmentisseen,iftheMFbitisset,alistitemwouldbeallocatedtoholdthe
resultofflteraccesschecks.Whenpacketswithanon-zeroFragment
Offsetcomein,lookupthelistelementwithamatchingSource Address/
Destination Address/Protocol/Identifcation and apply the stored result
(pass or block). When a fragment with a zero MFbitisseen,freethelist
element.Unfortunately,therulesofthistypeofpacketfltercanusuallybe
bypassed.[Ziembaetal,1995]describesthedetailsoftheinvolved
technique.

45
Security Assessment of the Internet Protocol
4.1.6 Possible security improvements
Memory allocation for fragment reassembly
A design choice usually has to be made as to how to allocate memory to
reassemble the fragments of a given packet. There are basically two options:
• Uponreceiptofthefrstfragment,allocateabufferlargeenoughto
concatenate the payload of each fragment.
• Uponreceiptofthefrstfragment,createthefrstnodeofalinkedlistto
which each of the following fragments will be linked. When all
fragmentshavebeenreceived,copytheIPpayloadofeachofthe
fragments (in the correct order) to a separate buffer that will be handed
to the protocol being encapsulated in the IP payload.
Whilethefrstofthechoicesmightseemtobethemoststraight-forward,it
implies that even when a single small fragment of a given packet is received
the amount of memory that will be allocated for that fragment will account for
thesizeofthecompleteIPdatagram,thususingmoresystemresourcesthan
what is actually needed.
Furthermore,theonlysituationinwhichtheactualsizeofthewholedatagram
willbeknowniswhenthelastfragmentofthepacketisreceivedfrst,asthat
is the only packet from which the total size of the IP datagram can be
asserted. Otherwise memory should be allocated for largest possible packet
size (65535 bytes).
The IP module should also enforce a limit on the amount of memory that can
beallocatedforIPfragments,aswellasalimitonthenumberoffragments
that will be allowed in the system at any time. This will basically limit the
resources spent on the reassembly process and prevent an attacker from
trashing the whole system memory.
Furthermore,theIPmoduleshouldkeepadifferentbufferforIPfragments
than for complete IP datagrams. This will basically separate the effects of
fragmentattacksonnon-fragmentedtraffc.MostTCP/IPimplementations,
suchasthatinLinuxandthoseinBSD-derivedsystems,alreadyimplement
this.
[Jones,2002]containsananalysisabouttheamountofmemorythatmaybe
needed for the fragment reassembly buffer depending on a number of
network characteristics.
Flushing the fragment buffer
In the case of those attacks that aim to consume the memory buffers used for
46
Security Assessment of the Internet Protocol
fragments,andthosethataimtocauseacollisionofIPIdentifcation
numbers,thereareanumberofcounter-measuresthatcanbeimplemented.
The IP module should enforce a limit on the amount of memory that can be
allocatedforIPfragments,aswellasalimitonthenumberoffragmentsthat
will 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-fragmentedtraffc.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
fushallorpartofthefragmentbufferonthepremisethatlegitimatetraffcwill
beabletomakeuseofthefreedbufferspacetoallowcommunicationfows
to progress.
There are a number of factors that should be taken into consideration when
fushingthefragmentbuffer.First,ifafragmentofagivenpacket(i.e.,
fragment with a given Identifcationnumber)isfushed,alltheother
fragmentsthatcorrespondtothesamedatagramshouldbefushed.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,intheeventthatsubsequentbufferfushesneedtobe
performed,itisnotalwaysthesamesetoffragmentsthatgetdroppedas
suchabehaviorwouldprobablycauseaselectiveDenialofService(DoS)to
thetraffcfowstowhichthatsetoffragmentsbelong.
ManyTCP/IPimplementationsdefneathresholdforthenumberoffragments
that,whenreached,triggerafragment-bufferfush.Somesystemsfush1/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,theideaoffushingasomewhatlargeportionofthebufferis
toavoidfushingalwaysthesamesetofpackets.
47
Security Assessment of the Internet Protocol
A more selective fragment buffer fushing strategy
Oneofthediffcultiesinimplementingcounter-measuresforthefragmentation
attacksdescribedinthisdocumentisthatitisdiffculttoperformvalidation
checksonthereceivedfragments.Forinstance,thefragmentonwhich
validitycheckscouldbeperformed,thefrstfragment,maybenotthefrst
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,asthefrstfragmentwereceiveforagiven
packetmaybesomeotherfragmentthanthefrstone(theonewithan
Fragment Offset of 0).
However,whenwedecidetofreesomespaceinthefragmentbuffer,some
refnementscanbedonetothefushingpolicy.Thefrstthingwewouldliketo
doistostopdifferenttypesoftraffcfrominterferingwitheachother.This
means,inprinciple,thatwedonotwantfragmentedUDPtraffctointerfere
withfragmentedTCPtraffc.Inordertoimplementthistraffcseparationfor
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
traffc.ThisbasicallymeansthattraffcnotprotectedbyIPsecwillnotinterfere
withthosefowsofcommunicationthatarebeingprotectedbyIPsec.
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,whenthebufferneedstobefushedthefollowingrefnedpolicycould
be applied:
• First,foreachpacketforwhichtheIPsecheaderhasbeenreceived
checkthattheSPIfeldoftheIPsecheadercorrespondstoanexisting
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,ifthefragmentbufferstillneedstobefusheddropallthe
fragments that correspond to packets for which the full IPsec header
has not yet been received. The number of packets for which this
fushingisperformeddependsontheamountoffreespacethatneeds
to be created.
48
Security Assessment of the Internet Protocol
• Third,ifthereisstillnotenoughspaceinthefragmentbufferafter
fushingpacketswithinvalidIPsecinformation(Firststep),andpackets
onwhichvalidationcheckscouldnotbeperformed(Secondstep),
drop all the fragments that correspond to packets that passed the
checksofthefrststepuntilthenecessaryfreespaceiscreated.
Therationalebehindthispolicyisthat,atthepointoffushingthefragment
buffer,weprefertokeepthosepacketsonwhichwecouldsuccessfully
perform a number of validation checks over those packets on which those
checksfailed,orcouldnotbeperformed.
BycheckingboththeIPsecSPIandtheIPsecsequencenumber,itisvirtually
impossibleforanattackerthatisoff-pathtoperformaDenialofServiceattack
tocommunicationfowsbeingprotectedbyIPsec.
UnfortunatelysomeTCP/IPstacks,whenperformingfragmentation,sendthe
correspondingfragmentsinreverseorder.Insuchcases,atthepointof
fushingthefragmentbuffer,legitimatefragmentswillreceivethesame
treatment as the possible forged fragments.
Thisrefnedfushingpolicyprovidesanincreasedlevelofprotectionagainst
thistypeofresourceexhaustionattack,whilenotmakingthesituationofout-
of-orderIPsec-securedtraffcworsethanwiththesimplifedfushingpolicy
described in the previous section.
Reducing the fragment timeout
RFC1122[Braden,1989]statesthatthereassemblytimeoutshouldbea
fxedvaluebetween60and120seconds.Therationalebehindtheselong
timeout values is that they should accommodate any path characteristics
suchaslong-delaypaths.Howeveritmustbenotedthatthistimerisreally
measuringinter-fragmentdelays,ormorespecifcally,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
Security Assessment of the Internet Protocol
techniquessuchasPMTUD[MogulandDeering,1990]orPLPMTUD[Mathis
andHeffner,2007].
Counter-measure for some IDS evasion techniques
[ShankarandPaxson,2003]introducesatechniquenamed“ActiveMapping”
thatpreventsevasionofaNIDSbyacquiringsuffcientknowledgeaboutthe
network being monitored to assess which packets will arrive at the intended
recipientandhowtheywillbeinterpretedbyit.[Novak,2005]describessome
techniquesthatareappliedbytheSnortNIDStoavoidevasion.
Counter-measure for frewall-rules bypassing
Oneoftheclassicaltechniquestobypassfrewallrulesinvolvessending
packets in which the header of the encapsulated protocol is fragmented. Even
whenitwouldbelegal(asfarastheIETFspecifcationsareconcerned)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-boxessuchasfrewallscreatestate
accordingtothecontentsofthefrstfragmentofagivenpacket,itisbestthat
intheeventanend-systemreceivesoverlappingfragmentsithonorsthe
informationcontainedinthefragmentthatwasreceivedfrst.
RFC1858[Ziembaetal,1995]describestheabuseofIPfragmentationto
bypassfrewallrules.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.
GiventhatitistrivialtoforgetheIPprecedencefeldoftheIPheader,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
Security Assessment of the Internet Protocol
disabledandallpacketswouldreceivethesametypeofservice,despitethe
values in their Type of Service or Differentiated Servicesfelds.
WhenPrecedence-orderedqueueserviceisrequiredinthenetwork
infrastructure in order to mitigate the attack vector discussed in the previous
paragraph,edgeroutersorswitchesshouldbeconfguredtopoliceand
remark the Type of Service or Differentiated Services values according to
thetypeofserviceatwhicheachend-systemhasbeenallowedtosend
packets.
Bullet4ofSection5.3.3.3ofRFC1812statesthatrouters“MUSTNOT
changeprecedencesettingsonpacketsitdidnotoriginate”.However,given
thesecurityimplicationsofthePrecedencefelditisfairforrouters,switches
orothermiddle-boxes,particularlythoseinthenetworkedge,tooverwritethe
Type of Service (or Differentiated Services)feldofthepacketstheyare
forwardingaccordingtoaconfgurednetworkpolicy.
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
thePrecedencefeld,itisimportanttonotethatitwouldbesimpleforan
attacker to send packets with forged high Precedence value to congest some
internetrouter(s)andcauseall(ormost)traffcwithalowerPrecedencevalue
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 TOSfeld.Therefore,theproposedalternativebehaviorisstill
compliantwiththeIETFspecifcations.
5
Security Assessment of the Internet Protocol
WhileoffciallyspecifedintheRFCseries,TOS-basedroutingisnotwidely
deployed in the Internet.
4.2.3 Address Resolution
Inthecaseofbroadcastlink-layertechnologies,inorderforasystemto
transferanIPdatagramitmustusuallyfrstmapanIPaddresstothe
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-existenthostwhichwouldsupposedlybedirectly
connected 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 is
received that requires an ARP request to be performed before the packet can
beforwarded,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
Security Assessment of the Internet Protocol
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 those
describedinRFC1918[Rekhteretal,1996],orthe“loopback”address),
there are a number of tricks an attacker can perform to reach them (e.g.
exploittheLSRRorSSRRIPoptions).Therefore,whenapplicable,packet
flteringshouldbeperformedatorganisationalnetworkboundarytoensure
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/8prefx)
• 172.16.0.0-172.31.255.255(172.16/12prefx)
• 192.168.0.0-192.168.255.255(192.168/16prefx)
UseoftheseaddressblocksisdescribedinRFC1918[Rekhteretal,1996].
Whereapplicable,packetflteringshouldbeperformedattheorganisational
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
Security Assessment of the Internet Protocol
currentlyreservedforexperimentaluse.Asaresult,anumberof
implementations discard packets that contain a Class E address as the
Source Address or Destination Address.
ThereisongoingworktoreclassifytheClassE(240/4)addressblockas
usableunicastaddressspaces[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
TheIETFspecifcationsdidnotoriginallypermitIPaddressestohavethe
value0or-1foranyoftheHostnumber,networknumberorsubnetnumber
felds,exceptforthecasesindicatedinSection4.3.7.Howeverthischanged
fundamentallywiththedeploymentofClasslessInter-DomainRouting(CIDR)
[FullerandLi,2006]becausewithCIDRasystemcannotknowwhatthe
subnet mask is for a particular IP address.
Manysystemsnowallowadministratorstousethevalues0or-1forthose
felds.DespitethataccordingtotheIETFspecifcationstheseaddressesare
illegal,modernIPimplementationsshouldconsidertheseaddressestobe
valid.
4.3.7 Special Internet addresses
RFC1812[Baker,1995]discussestheuseofsomespecialinternet
addresses,whichisofinteresttoperformsomesanitychecksontheSource
Address and Destination AddressfeldsofanIPpacket.Itusesthe
following notation for an IP address:
{<Network-prefx>,<Host-number>}
RFC1122[Braden,1989]containedasimilardiscussionofspecialinternet
addresses,includingsomeoftheform{<Network-prefx>,<Subnet-number>,
<Host-number>}.However,asexplainedinSection4.2.2.11ofRFC1812,in
aCIDRworld,thesubnetnumberisclearlyanextensionofthenetworkprefx
andcannotbeinterpretedwithouttheremainderoftheprefx.
54
Security Assessment of the Internet Protocol
{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 any
purposeotherthanbootstrapping,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“thespecifedhost,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. This
shouldbeconsideredabug,ratherthanamalicioususeofthelimited
broadcast address.
{Network number, -1}
Thisisthedirectedbroadcasttothespecifednetwork.Asrecommendedby
RFC2644[Senie,1999],routersshouldnotforwardnetwork-directed
broadcasts.Thisavoidsthecorrespondingnetworkfrombeingutilisedas,for
example,a“smurfamplifer”[CERT,1998a].
AsnotedinSection4.3.6ofthisdocument,manysystemsnowallow
administratorstoconfguretheseaddressesasunicastaddressesfornetwork
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.thatIPaddressisconfguredonthelocalsystemasa“broadcast
address”). If a system can infer the Source Address of a received packet is a
network-directedbroadcastaddressthepacketshouldbedropped.
55
Security Assessment of the Internet Protocol
AsnotedinSection4.3.6ofthisdocument,withthedeploymentofCIDR
[Fuler,2006],itmaybediffcultforasystemtoinferwhetheraparticularIP
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
Security Assessment of the Internet Protocol
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 Communication
Review,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 Spoofng Attacks. Available at:
http://www.cert.org/advisories/CA-1996-21.html
CERT. 996c. CERT Advisory CA-1996-26: Denial-of-Service Attack via ping. Available at:
http://www.cert.org/advisories/CA-1996-26.html
CERT. 997. CERT Advisory CA-1997-28: IP Denial-of-Service Attacks. Available at:
http://www.cert.org/advisories/CA-1997-28.html
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
Security Assessment of the Internet Protocol
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:
http://www.cert.org/advisories/CA-1999-17.html
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:
http://www.cert.org/advisories/CA-2003-15.html
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. Working
Group 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 Confguration Guide, Release 12.2. Available at:
http://www.cisco.com/en/US/docs/ios/12_2/security/confguration/guide/scfpso.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,andinfnity.1996. IP-spoofng Demystifed (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 Spoofng. 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/fps/fps188/
fps188.pdf
Fuller,V.,Li,T.2006.ClasslessInter-domainRouting(CIDR):The Internet Assignment and
Aggregation Plan. RFC 4632.
58
Security Assessment of the Internet Protocol
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/4as usable unicast address space. IETF
Internet-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 fltering. Available at:
http://www.gont.com.ar/papers/icmp-fltering.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
Security Assessment of the Internet Protocol
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/fles/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.Defnition 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
Security Assessment of the Internet Protocol
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, Traffc
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 Specifcation. 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 Notifcation
(ECN) to IP. RFC 368.
Rekhter,Y.,Moskowitz,B.,Karrenberg,D.,deGroot,G.J.,andLear,E.1996.Address Allocation for
Private Internets. RFC 98.
Sanflippo,S.1998a.about the ip header id.PosttoBugtraqmailing-list,MonDec141998.Available
at: http://www.kyuzz.org/antirez/papers/ipid.html
Sanflippo,S.1998b. Idle scan.PosttoBugtraqmailing-list.Availableat:
http://www.kyuzz.org/antirez/papers/dumbscan.html
Sanflippo,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/
6
Security Assessment of the Internet Protocol
Senie,D.1999.Changing the Default for Directed Broadcasts in Routers. RFC 2644.
Shankar,U.,andPaxson,V.2003.Active Mapping: Resisting NIDS EvasionWithout Altering Traffc.
Available at: http://www.icir.org/vern/papers/activemap-oak03.pdf
Shannon,C.,Moore,D.,andClaffy,K.C.2001.Characteristics of Fragmented IP Traffc 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 sacrifcing
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 frewall 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.,andHaddad,I.2002.Linux Distributed Security Module.LinuxJournal.Availableat:
http://www.linuxjournal.com/article/6215
Ziemba,G.,Reed,D.,andTraina,P.1995.Security Considerations for IP Fragment Filtering. RFC
858.

Sign up to vote on this title
UsefulNot useful