Security Assessment of the Internet Protocol
-
Upload
chris-nash -
Category
Documents
-
view
217 -
download
0
Transcript of Security Assessment of the Internet Protocol
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 1/63
Security ASSeSSment
of the internet Protocol
july 2008
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 2/63
Written by Fernando Gont on behalf of CPNI.
Disclaimer
Reference to any specic commercial product, process or service by trade name, trademark manufacturer, or otherwise,
does not constitute or imply its endorsement, recommendation, or favouring by CPNI. The views and opinions of authors
expressed within this document shall not be used for advertising or product endorsement purposes.
To the fullest extent permitted by law, CPNI accepts no liability for any loss or damage (whether direct, indirect or
consequential and including, but not limited to, loss of prots or anticipated prots, loss of data, business or goodwill)
incurred by any person and howsoever caused arising from or connected with any error or omission in this document
or from any person acting, omitting to act or refraining form acting upon, or otherwise using, the information contained
in this document or its references. You should make your own judgement as regards to use of this document and seek
independent professional advice on your particular circumstances.
www.cpni.gov.uk
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 3/63
Security Assessment of the Internet Protocol
Table of Contents
1. Preface ..................................................................................................................................... 3
. Introduction ..................................................................................................................... 3
.2 Scope of this document .................................................................................................. 4
.3 Organization of this document ......................................................................................... 4
.4 Typographical conventions .............................................................................................. 5
.5 Getting the latest version of this document ....................................................................... 5
.6 Advice and guidance to vendors ...................................................................................... 5
.5 Acknowledgements ......................................................................................................... 5
2. The Internet Protocol .............................................................................................................. 6
3. Internet Protocol header elds .............................................................................................. 7
3. Version ............................................................................................................................. 7
3.2 IHL (Internet Header Length) ............................................................................................ 8
3.3 TOS ................................................................................................................................. 8
3.4 Total Length ..................................................................................................................... 9
3.5Identication(ID) ............................................................................................................. 0
3.5. Some workarounds implemented by the industry ........................................................ 0
3.5.2 Possible security improvements ..................................................................................
3.6 Flags .............................................................................................................................. 3
3.7 Fragment Offset ............................................................................................................. 4
3.8 Time to Live (TTL) ........................................................................................................... 5
3.9 Protocol ......................................................................................................................... 9
3.0 Header Checksum ....................................................................................................... 9
3. Source Address ........................................................................................................... 9
3.12DestinationAddress ..................................................................................................... 20
3.3 Options ........................................................................................................................ 20
3.3. General issues with IP options ................................................................................... 2
3.3.. Processing requirements ........................................................................................ 2
3.3..2 Processing of the options by the upper layer protocol ............................................ 22
3.3..3 General sanity checks on IP options ....................................................................... 22
3.13.2Issueswithspecicoptions ....................................................................................... 23
3.3.2. End of Option List (Type = 0) .................................................................................. 23
3.3.2.2 No Operation (Type = ) ......................................................................................... 24
3.3.2.3 Loose Source Record Route (LSRR) (Type = 3) .................................................. 24
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 4/63
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.6StreamIdentier(Type=136) ................................................................................. 3
3.3.2.7 Internet Timestamp (Type = 68) .............................................................................. 3
3.3.2.8 Router Alert (Type = 48) ........................................................................................ 34
3.3.2.9 Probe MTU (Type =) ........................................................................................... 34
3.3.2.0 Reply MTU (Type = 2) ......................................................................................... 34
3.3.2. Traceroute (Type = 82) .......................................................................................... 35
3.13.2.12DoDBasicSecurityOption(Type=130)............................................................... 35
3.13.2.13DoDExtendedSecurityOption(Type=133)......................................................... 36
3.3.2.4 Commercial IP Security Option (CIPSO)................................................................ 36
3.13.2.15SenderDirectedMulti-DestinationDelivery(Type=149) ....................................... 37
3.14DifferentiatedServiceseld.......................................................................................... 37 3.15ExplicitCongestionNotication(ECN) ......................................................................... 38
4. Internet Protocol Mechanisms ............................................................................................. 40
4. Fragment reassembly .................................................................................................... 40
4.. Problems related with memory allocation .................................................................... 4
4.1.2ProblemsthatarisefromthelengthoftheIPIdenticationeld................................... 42
4.1.3Problemsthatarisefromthecomplexityofthereassemblyalgorithm ......................... 43
4..4 Problems that arise from the ambiguity of the reassembly process ............................. 434..5 Problems that arise from the size of the IP fragments ................................................. 44
4..6 Possible security improvements ................................................................................. 45
4.2 Forwarding .................................................................................................................... 49
4.2.1Precedence-orderedqueueservice............................................................................ 49
4.2.2 Weak Type of Service ................................................................................................. 50
4.2.3 Address Resolution .................................................................................................... 5
4.2.4Droppingpackets....................................................................................................... 5
4.3 Addressing .................................................................................................................... 52
4.3. Unreachable addresses .............................................................................................. 52
4.3.2 Private address space ................................................................................................ 52
4.3.3ClassDaddresses(224/4addressblock)................................................................... 52
4.3.4ClassEaddresses(240/4addressblock)................................................................... 52
4.3.5Broadcastandmulticastaddresses,andconnection-orientedprotocols .................... 53
4.3.6Broadcastandnetworkaddresses............................................................................. 53
4.3.7 Special Internet addresses ......................................................................................... 53
5. References ............................................................................................................................. 56
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 5/63
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,manyprotocolspecicationsfocusonlyontheoperationalaspectsoftheprotocols
they specify and overlook their security implications.
ThoughInternettechnologyhasevolved,thebuildingblocksarebasicallythesamecore
protocolsadoptedbytheARPANETmorethantwodecadesago.Duringthelasttwenty
yearsmanyvulnerabilitieshavebeenidentiedintheTCP/IPstacksofanumberof
systems.Somewereawsinprotocolimplementationswhichaffectonlyareduced
numberofsystems.Otherswereawsintheprotocolsthemselvesaffectingvirtuallyevery
existingimplementation[Bellovin,1989].Eveninthelastcoupleofyearsresearcherswere
stillworkingonsecurityproblemsinthecoreprotocols[Gont,2008][Watson,2004]
[NISCC,2004][NISCC,2005].
ThediscoveryofvulnerabilitiesintheTCP/IPprotocolsledtoreportsbeingpublishedbya
numberofCSIRTs(ComputerSecurityIncidentResponseTeams)andvendors,which
helped to raise awareness about the threats as well as the best mitigations known at the
time the reports were published.
Much of the effort of the security community on the Internet protocols did not result in
ofcialdocuments(RFCs)beingissuedbytheIETF(InternetEngineeringTaskForce)
leading to a situation in which “known” security problems have not always been
addressedbyallvendors.Inmanycasesvendorshaveimplementedquick“xes”to
protocolawswithoutacarefulanalysisoftheireffectivenessandtheirimpacton
interoperability[Silbersack,2005].
Asaresult,anysystembuiltinthefutureaccordingtotheofcialTCP/IPspecications
mightreincarnatesecurityawsthathavealreadyhitourcommunicationsystemsinthe
past.
ProducingasecureTCP/IPimplementationnowadaysisaverydifculttaskpartly
because of no single document that can serve as a security roadmap for the protocols.
ThereisclearlyaneedforacompaniondocumenttotheIETFspecicationsthat
discussesthesecurityaspectsandimplicationsoftheprotocols,identiesthepossible
threats,proposespossiblecounter-measures,andanalysestheirrespectiveeffectiveness.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 6/63
4
Security Assessment of the Internet Protocol
ThisdocumentistheresultofanassessmentoftheIETFspecicationsoftheInternet
Protocolfromasecuritypointofview.Possiblethreatswereidentiedand,where
possible,counter-measureswereproposed.Additionally,manyimplementationawsthat
have led to security vulnerabilities have been referenced in the hope that future
implementations will not incur the same problems. This document does not limit itself toperformingasecurityassessmentoftherelevantIETFspecicationbutalsooffersan
assessment of common implementation strategies.
WhilstnotaimingtobethenalwordonthesecurityoftheIP,thisdocumentaimstoraise
awareness about the many security threats based on the IP protocol that have been faced
inthepast,thosethatwearecurrentlyfacing,andthosewemaystillhavetodealwithin
thefuture.ItprovidesadviceforthesecureimplementationoftheIP,andalsoinsights
about the security aspects of the IP that may be of help to the Internet operations
community.
Feedback from the community is more than encouraged to help this document be asaccurate as possible and to keep it updated as new threats are discovered.
1.2 Scope of this document
WhilethereareanumberofprotocolsthataffectthewayinwhichIPsystemsoperate,
thisdocumentfocusesonlyonthespecicationsoftheIP.Forexample,routingand
bootstrapping protocols are considered out of the scope of this project.
The following IETF RFCs were selected for assessment as part of this work:
• RFC791,“InternetProtocol.DARPAInternetProgram.ProtocolSpecication”(51
pages).
• RFC815,“IPdatagramreassemblyalgorithms”(9pages).
• RFC1122,“RequirementsforInternetHosts--CommunicationLayers”(116
pages).
• RFC1812,“RequirementsforIPVersion4Routers”(175pages).
• RFC2474,“DenitionoftheDifferentiatedServicesField(DSField)intheIPv4and
IPv6 Headers” (20 pages).
• RFC2475,“AnArchitectureforDifferentiatedServices”(36pages).
• RFC3168,“TheAdditionofExplicitCongestionNotication(ECN)toIP”(63pages).
1.3 Organisation of this document
Thisdocumentisbasicallyorganisedintwoparts:“InternetProtocolheaderelds”and
“InternetProtocolmechanisms”.Theformercontainsananalysisofeachoftheeldsof
theInternetProtocolheader,identiestheirsecurityimplications,anddiscussesthe
possiblecounter-measures.Thelattercontainsananalysisofthesecurityimplicationsof
the mechanisms implemented by the Internet Protocol.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 7/63
5
Security Assessment of the Internet Protocol
1.4 Typographical conventions
ThroughoutthisdocumenttheheadereldsoftheInternetProtocolsarediscussedin
detail.Insomecases,agiventermmayhaveaslightlydifferentmeaningdependingon
whetheritisusedtorefertoaconceptortoaspeciceldoftheInternetProtocolheader.Toavoidanypossibleconfusionarisingfromthisambiguity,whenreferringtoa
speciceldoftheIPheaderthenameoftheeldiswritteninthisfont type.
Throughoutthedocumenttherearealsoanumberofparentheticalnotessuchasthisone,
toprovideadditionaldetailsorclarications.
1.5 Getting the latest version of this document
Itisexpectedthatrevisionsofthisdocumentwillbepublishedinresponsetothe
feedback provided by the community. Revisions of this document will be available at:
www.cpni.gov.uk/Products/technical.aspx
1.6 Advice and guidance to vendors
Vendors are urged to contact CPNI’s Vulteam ([email protected]) if they think they may
be affected by the issues described in this document. As the lead coordination center for
theseissues,CPNIiswellplacedtogiveadviceandguidanceasrequired.
CPNIworksextensivelywithgovernmentdepartmentsandagencies,commercial
organisations and the academic community to research vulnerabilities and potential
threatstoITsystems,especiallywheretheymayhaveanimpactonCriticalNationalInfrastructure’s (CNI).
OtherwaystocontactCPNI,plusCPNI’sPGPpublickey,areavailableat
www.cpni.gov.uk.
1.7 Acknowledgements
This assessment was written by Fernando Gont on behalf of CPNI.
TheauthorwouldliketothankRandallAtkinson,JohnDay,JuanFraschini,RoqueGagliano,GuillermoGont,MartinMarino,PekkaSavola,andChristosZoulasforproviding
valuable comments on earlier versions of this document.
TheauthorwouldliketothankRandallAtkinsonandRoqueGagliano,whogenerously
answered a number of questions.
Finally,theauthorwouldliketothankCPNIfortheircontinuedsupport.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 8/63
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.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 9/63
7
Security Assessment of the Internet Protocol
3. Internet Protocol header elds
TheIETFspecicationsoftheInternetProtocoldenethesyntaxoftheprotocolheader,
alongwiththesemanticsofeachofitselds.Figure1showstheformatofanIP
datagram.
Figure : Internet Protocol header format
EvenwhentheminimumIPheadersizeis20bytes,anIPmodulemightbehandedan
(illegitimate)“datagram”oflessthan20bytes.Therefore,beforedoinganyprocessingof
theIPheaderelds,thefollowingcheckshouldbeperformedbytheIPmoduleonthepacketshandedbythelink-layer:
link-layer.PayloadSize>=20
If the packet does not pass this check it should be dropped.
The following subsections contain further sanity checks that should be performed on IP
packets.
3.1 Version
Thisisa4-biteldthatindicatestheversionoftheIP,andthusthesyntaxofthepacket.
ForIPv4,thiseldmustbe4.
Whenalink-layerprotocolde-multiplexesapackettoaninternetmodule,itdoesso
basedona“ProtocolType”eldinthedata-linkpacketheader.
Intheory,differentversionsofIPcouldcoexistonanetworkbyusingthesame“Protocol
Type”atthelink-layer,butadifferentvalueintheVersioneldoftheIPheader.Thusa
singleIPmodulecouldhandleallversionsoftheInternetProtocol,differentiatingthemby
meansofthiseld.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 10/63
8
Security Assessment of the Internet Protocol
However,inpracticedifferentversionsofIPareidentiedbyadifferent“ProtocolType”
numberinthelink-layerprotocolheader.Forexample,IPv4datagramsareencapsulated
inEthernetframesusinga“ProtocolType”eldof0x0800,whileIPv6datagramsare
encapsulatedinEthernetframesusinga“ProtocolType”eldof0x86DD[IANA,2006a].
ThereforeifanIPv4modulereceivesapacket,the Versioneldmustbecheckedtobe4.
If this check fails the packet should be silently dropped.
3.2 IHL (Internet Header Length)
TheIHL(InternetHeaderLength)indicatesthelengthoftheinternetheaderin32-bit
words(4bytes).Astheminimumdatagramsizeis20bytes,theminimumlegalvaluefor
thiseldis5andthefollowingcheckshouldbeenforced:
IHL>=5
Forobviousreasons,theInternetheadercannotbelargerthanthewholeInternet
datagram it is part of and therefore the following check should be enforced:
IHL * 4 <= Total Length
TheabovecheckallowsforInternetdatagramswithnodatabytesinthepayloadthat,
whilenonsensicalforvirtuallyeveryprotocolthatrunsoverIP,isstilllegal.
3.3 TOS
Figure2showsthesyntaxoftheType of Service eld,denedbyRFC791[Postel,
1981],andupdatedbyRFC1349[Almquist,1992].
Figure2:TypeofServiceeld
Bits 0-2: Precedence.
Bit 3: 0=NormalDelay,1=LowDelay.
Bits 4: 0=NormalThroughput,1=HighThroughput.
Bit 5: 0=NormalReliability,1=HighReliability.
Bit 6: 0=NormalCost,1=MinimiseMonetaryCost
Bits 7: ReservedforFutureUse(mustbezero).
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 11/63
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 Serviceeldcanbeusedtoaffectthewayinwhichthepacketistreatedby
thesystemsofanetworkthatprocessit.Section4.2.1(“Precedence-orderedqueue
service”) and Section 4.2.3 (“Weak TOS”) of this document describe the securityimplications of the Type of Serviceeldintheforwardingofpackets.
3.4 Total Length
The Total Lengtheldisthelengthofthedatagram,measuredinbytes,includingboth
theIPheaderandtheIPpayload.Beinga16-biteld,itallowsfordatagramsofupto
65535bytes.RFC791[Postel,1981]statesthatallhostsshouldbepreparedtoreceive
datagramsofupto576bytes(whethertheyarriveasawholeorinfragments).However,
most modern implementations can reassemble datagrams of at least 9 Kbytes.
Usually a host will not send to a remote peer an IP datagram larger than 576 bytes unless
itisexplicitlysignaledthattheremotepeerisabletoreceivesuch“large”datagrams(for
example,bymeansofTCP’sMSSoption).However,systemsshouldassumethatthey
may be sent datagrams larger than 576 bytes regardless of whether they signal their
remotepeerstodosoornot.InfactitiscommonforNFS[Shepleretal,2003]
implementationstosenddatagramslargerthan576bytes,evenwithoutexplicitsignaling
that the destination system can receive such “large” datagram.
Additionally,seethediscussioninSection4.1“Fragmentreassembly”regardingthepossible
packet sizes resulting from fragment reassembly.
Implementations should be aware that the IP module could be handed a packet larger
thanthevalueactuallycontainedintheTotalLengtheld.Suchadifferenceusuallyhasto
dowithlegitimatepaddingbytesatthelink-layerprotocol,butitcouldalsobetheresultof
maliciousactivitybyanattacker.Furthermore,evenwhenthemaximumlengthofanIP
datagramis65535bytes,ifthelink-layertechnologyinuseallowsforpayloadslargerthan
65535bytesanattackercouldforgesuchalargelink-layerpacket,meaningitfortheIP
module. If the IP module of the receiving system were not prepared to handle such an
oversizedlink-layerpayloadanunexpectedfailuremightoccur.Therefore,thememory
bufferusedbytheIPmoduletostorethelink-layerpayloadshouldbeallocatedaccording
tothepayloadsizereportedbythelink-layer,ratherthanaccordingtotheTotalLength
eldoftheIPpacketitcontains.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 12/63
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 Lengtheld.Thiscouldbeused,forexample,toproducean
information leakage. Therefore the following check should be performed:
Link-layer.PayloadSize>=Total Length
IfthischeckfailstheIPpacketshouldbedropped.Asthepreviousexpressionimplies,
thenumberofbytespassedbythelink-layertotheIPmoduleshouldcontainatleastas
many bytes as claimed by the Total LengtheldoftheIPheader.
[US-CERT,2002]isanexampleoftheexploitationofaforgedIPTotal Lengtheldto
produce an information leakage attack.
3.5 Identication (ID)
The Identicationeldissetbythesendinghosttoaidinthereassemblyoffragmented
datagrams.Atanytime,itneedstobeuniqueforeachsetof{Source Address,
Destination Address, Protocol}.
InmanysystemsthevalueusedforthiseldisdeterminedattheIPlayeronaprotocol-
independent basis. Many of those systems also simply increment the IP Identication
eldforeachpackettheysend.
Thisimplementationstrategyisinappropriateforanumberofreasons.First,ifthe
Identicationeldissetonaprotocol-independentbasis,itwillwrapmoreoftenthan
necessary,andthustheimplementationwillbemorepronetotheproblemsdiscussedin[KentandMogul,1987]and[Heffner,Mathis,andChandler,2006].
Secondly,thisimplementationstrategyopensthedoortoaninformationleakagethatcan
beexploitedtoinanumberofways.[Sanlippo,1998a]originallypointedouthowthis
eldcouldbeexaminedtodeterminethepacketrateatwhichagivensystemis
transmittinginformation.Later,[Sanlippo,1998b]describedhowasystemwithsuchan
implementation can be used to perform a stealth port scan to a third (victim) host.
[Sanlippo,1999]explainedhowtoexploitthisimplementationstrategytouncoverthe
rulesofanumberofrewalls.[Bellovin,2002]explainshowtheIPIdenticationeldcan
beexploitedtocountthenumberofsystemsbehindaNAT.[Fyodor,2004]isanentire
paperonmost(ifnotall)thewaystoexploittheinformationprovidedbytheIdenticationeldoftheIPheader.
3.5.1 Some workarounds implemented by the industry
As the IP Identicationeldisonlyusedforthereassemblyofdatagrams,
someoperatingsystems(suchasLinux)decidedtosetthiseldto0inall
packetsthathavetheDFbitset.Thiswould,inprinciple,avoidanytypeof
informationleakage.However,itwasdetectedthatsomenon-RFC-compliant
middle-boxesfragmentedpacketseveniftheyhadtheDFbitset.Insucha
scenarioalldatagramsoriginallysentwiththeDFbitsetwouldresultin
fragments that would have an Identicationeldof0,whichwouldleadto
problems(“collision”oftheIdenticationnumber)inthereassemblyprocess.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 13/63
Security Assessment of the Internet Protocol
Linux(andSolaris)latersettheIPIdenticationeldonaper-IP-address
basis. This avoids some of the security implications of the IP Identication
eld,butnotall.Forexample,systemsbehindaloadbalancercanstillbe
counted.
3.5.2 Possible security improvements
Contrarytocommonwisdom,theIP Identicationelddoesnotneedtobe
system-wideuniqueforeachpacket,buthastobeuniqueforeach{Source
Address, Destination Address, Protocol} tuple.
Forinstance,theTCPspecicationdenesagenericsend()functionwhich
takestheIPIDasoneofitsarguments.
We provide an analysis of the possible security improvements that could be
implemented,basedonwhethertheprotocolusingtheservicesofIPisconnection-orientedorconnection-less.
Connection-oriented protocols
Toavoidthesecurityimplicationsoftheinformationleakagedescribedabove,
apseudo-randomnumbergenerator(PRNG)couldbeusedtosettheIP
Identicationeldona{Source Address, Destination Address} basis (for
eachconnection-orientedtransportprotocol).
[Klein,2007]isasecurityadvisorythatdescribesaweaknessinthepseudo
random number generator (PRNG) in use for the generation of the IPIdentication by a number of operating systems.
Whileintheoryapseudo-randomnumbergeneratorcouldleadtoscenarios
in which a given Identication number is used more than once in the same
time-spanfordatagramsthatendupgettingfragmented(withthe
correspondingpotentialreassemblyproblems),inpracticethisisunlikelyto
cause trouble.
Bydefault,mostimplementationsofconnection-orientedprotocols,suchas
TCP,implementsomemechanismforavoidingfragmentation(suchasthe
Path-MTUDiscoverymechanism[MogulandDeering,1990]).Thus,
fragmentationwillonlytakeplacesporadicallywhenanon-RFC-compliant
middle-boxisplacedsomewherealongthepaththatthepacketstraveltoget
tothedestinationhost.Oncethesendingsystemissignaledbythemiddle-
boxthatitshouldreducethesizeofthepacketsitsends,fragmentation
wouldbeavoided.Also,forreassemblyproblemstoarise,thesame
Identicationeldshouldbefrequentlyreusedandeitherstrongpacket
reordering or packet loss should take place.
Nevertheless,regardlessofwhatpolicyisusedforselectingthe
Identicationeld,withthecurrentlinkspeedsfragmentationisalreadybad
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 14/63
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:
• lackofow-controlmechanisms,
• lack of packet sequencing mechanisms
• lack of reliability mechanisms (such as “timeout and retransmit”).
Thismeansthatthescenariosand/orapplicationsforwhichconnection-less
transport protocols are used assume that:
• Applications will be used in environments in which packet reordering is
veryunlikely(suchasLocalAreaNetworks),asthetransportprotocol
itself does not provide data sequencing.
• Thedatatransferrateswillbelowenoughthatowcontrolwillbe
unnecessary.
• Packet loss is not important and probably also unlikely.
Withtheseassumptionsinmind,theIdenticationeldcouldstillbeset
accordingtoapseudo-randomnumbergenerator(PRNG).Intheeventa
given Identicationnumberwasreusedwhiletherstinstanceofthesame
numberisstillonthenetwork,therstIPdatagramwouldbereassembled
before the fragments of the second IP datagram get to their destination.
Intheeventthiswasnotthecase,thereassemblyoffragmentswouldresult
inacorruptdatagram.Whilesomeexistingwork[Silbersack,2005]assumes
thatthiserrorwouldbecaughtbysomeupper-layererrordetectioncode,the
errordetectioncodeinquestion(suchasUDP’schecksum)mightbeintended
todetectsinglebiterrors,ratherthandatacorruptionarisingfromthe
replacement of a complete data block (as is the case in corruption arising
from collision of IP Identication numbers).
InthecaseofUDP,unfortunatelysomesystemshavebeenknowntonot
enabletheUDPchecksumbydefault.Formostapplications,packetscontaining errors should be dropped. Probably the only application that maybenetfromdisablingthechecksumisstreamingmedia,toavoiddroppinga
completesampleforasingle-biterror.
Ingeneral,ifIPIdentication number collisions become an issue for the
applicationusingtheconnection-lessprotocol,thenuseofadifferent
transport protocol (which hopefully avoids fragmentation) should be
considered.
AnattackercouldintentionallyexploitcollisionsofIPIdentication numbers
toperformaDenialofServiceattackbysendingforgedfragmentsthatwouldcausethereassemblyprocesstoresultinacorruptdatagram,thatwould
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 15/63
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
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 16/63
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 17/63
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.
SuchadatagramwouldresultwhentherstfragmenthasaFragment Offset of 0 and a
Total Lengthof65532,andthesecond(andlast)fragmenthasaFragment Offset of 8189(65512bytes),andaTotal Length of 65535. Assuming an IHLof5(i.e.,aheader
lengthof20bytes),thereassembleddatagramwouldbe65532+(65535–20)=131047
bytes.
The IP module should implement all the necessary measures to be able to handle such
illegitimatereassembleddatagrams,soastoavoidthemfromoverowingthebuffer(s)
used for the reassembly function.
[CERT,1996c]and[Kenney,1996]describetheexploitationofthisissuetoperformaDenial
ofService(DoS)attack.
3.8 Time to Live (TTL)
The Time to Live (TTL)eldhastwofunctions:tobindthelifetimeoftheupper-layer
packets(e.g.TCPsegments)andtopreventpacketsfromloopingindenitelyinthenetwork.
Originally,thiseldwasmeanttoindicatemaximumtimeadatagramwasallowedto
remain within the internet system in units of seconds. As every internet module that
processes a datagram must decrement the TTLbyatleastone,theoriginaldenitionof
the TTLeldbecameobsolete,anditmustnowbeinterpretedasahopcount.
MostsystemsallowtheadministratortoconguretheTTLtobeusedforthepacketssent
with the default value usually being a power of 2. The recommended value for the TTL
eld,asspeciedbytheIANAis64[IANA,2006b].Thisvaluereectstheassumed“diameter” of the Internet plus a margin to accommodate its growth.
The TTLeldhasanumberofpropertiesthatareinterestingfromasecuritypointofview.
Given that the default value used for the TTL is usually a power of eight the chances are
that,unlesstheoriginatingsystemhasbeenexplicitlytunedtouseanon-defaultvalue,if
a packet arrives with a TTL of 60 the packet was originally sent with a TTL of 64. In the
same way if a packet is received with a TTL of 20 chances are that the original packet
had a TTL of 28.
Thisdiscussionassumestherewasnoprotocolscrubber,transparentproxy,orsomeother
middle-boxthatoverwritestheTTLeldinanon-standardway,betweentheoriginatingsystem and the point of the network in which the packet was received.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 18/63
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
responsesfromthedevicesbeingngerprintedandeachresponsethatarriveswitha
different TTL could be assumed to come from a different device.
Ofcourse,thereareothermoreprecisetechniquestongerprintphysicaldevices.Amongst
thedrawbacksofthismethod,whilemanysystemsdifferinthedefaultTTL they use for thepacketstheysend,therearealsomanyimplementationswhichusethesamedefaultTTL. Additionally,packetssentbyagivendevicemaytakedifferentroutes(e.g.duetoload
sharing or route changes) and thus a given packet may incorrectly be presumed to comefrom a different device when in fact it just traveled a different route.
Locating the source host in the network topology
The TTLeldmayalsobeusedtolocatethesourcesysteminthenetworktopology
[NorthcuttandNovak,2000].
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 19/63
7
Security Assessment of the Internet Protocol
Figure4:TrackingahostbymeansoftheTTLeld
ConsidernetworktopologyofFigure4.Assumingthatanattacker(“F”inthegure)is
performing an attack that requires forging the Source Address(suchasaTCP-based
DoSreectionattack),andsomeoftheinvolvedhostsarewillingtocooperatetolocate
the attacking system.
Assuming that:
• All the packets A gets have a TTL of 6. • AllthepacketsBgetshaveaTTL of 6.
• All the packets C gets have a TTL of 6.
• AllthepacketsDgetshaveaTTL of 62.
Basedonthisinformation,andassumingthatthesystem’sdefaultvaluewasnot
overridden,itwouldbefairtoassumethattheoriginalTTL of the packets was 64. With
this information the number of hops between the attacker and each of the aforementioned
hosts can be calculated.
The attacker is:
• Three hops away from A.
• ThreehopsawayfromB.
• Three hops away from C.
• TwohopsawayfromD.
InthenetworksetupofFigure3,theonlysystemthatsatisesalltheseconditionsisthe
one marked as the “F”.
Thescenariodescribedaboveisforillustrationpurposesonly.Inpractice,therearea
number of factors that may prevent this technique from being successfully applied:
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 20/63
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 TTLeldcanbeusedtoevadeNetworkIntrusionDetectionSystems.Dependingon
thepositionofasensorrelativetothedestinationhostoftheexaminedpacket,theNIDS
maygetadifferentpicturefromthatoftheintendeddestinationsystem.Asanexample,a
sensormayprocessapacketthatwillexpirebeforegettingtothedestinationhost.A
generalcounter-measureforthistypeofattackistonormalisethetrafcthatgetstoan
organisationalnetwork.Examplesofsuchtrafcnormalisationcanbefoundin[Paxsonet
al,2001].
Improving the security of applications that make use of the Internet
Protocol (IP)
In some scenarios the TTLeldcanbealsousedtoimprovethesecurityofanapplication
byrestrictingthehoststhatcancommunicatewiththegivenapplication.Forexample,
there are applications for which the communicating systems are typically in the samenetworksegment(i.e.,therearenointerveningrouters).SuchanapplicationistheBGP
(BorderGatewayProtocol)betweenutilisedbytwopeerrouters.
If both systems use a TTLof255forallthepacketstheysendtoeachother,thena
check could be enforced to require all packets meant for the application in question to
have a TTL of 255.
As all packets sent by systems that are not in the same network segment will have a TTL
smallerthan255,thosepacketswillnotpassthecheckenforcedbythesetwo
cooperating peers. This check reduces the set of systems that may perform attacks
againsttheprotectedapplication(BGPinthiscase),thusmitigatingtheattackvectors
describedin[NISCC,2004]and[Watson,2004].
ThissamecheckisenforcedforrelatedICMPerrormessages,withtheintentofmitigating
theattackvectorsdescribedin[NISCC,2005]and[Gont,2008].
.
The TTLeldcansimilarlybeusedinscenariosinwhichthecooperatingsystemseither
do not use a default TTLof255,orarenotinthesamenetworksegment(i.e.,multi-hop
peering).Inthatcase,thefollowingcheckcouldbeenforced:
TTL>=255-Δhops
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 21/63
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 TTLeldforprotectingmulti-hoppeeringstillreducesthesetofhoststhat
could potentially perform a number of attacks against the protected application.
This use of the TTLeldhasbeenofciallydocumentedbytheIETFunderthename
“GeneralisedTTLSecurityMechanism”(GTSM)in[Gilletal,2007].
Some protocol scrubbers enforce a minimum value for the TTLeldofthepacketsthey
forward. It must be understood that depending on the minimum TTLbeingenforced,and
dependingontheparticularnetworksetup,theprotocolscrubbermayactuallyhelp
attackerstofooltheGTSM,by“raising”theTTL of the attacking packets.
3.9 Protocol
The Protocoleldindicatestheprotocolencapsulatedintheinternetdatagram.The
Protocoleldmaynotonlycontainavaluecorrespondingtoanimplementedprotocol
within the system but also a value corresponding to a protocol not implemented or even a
valuenotyetassignedbytheIANA[IANA,2006c].
While in theory there should not be security implications from the use of any value in the
protocoleld,therehavebeensecurityissuesinthepastwithsystemsthathadproblems
whenhandlingpacketswithsomespecicprotocolnumbers[Cisco,2003][CERT,2003].
3.10 Header Checksum
The Header Checksumeldisanerrordetectionmechanismmeanttodetecterrorsin
the IP header. While in principle there should not be security implications arising from this
eld,itshouldbenotedthatduetonon-RFC-compliantimplementations,theHeader
Checksummightbeexploitedtodetectrewallsand/orevadenetworkintrusion
detectionsystems(NIDS).
[Ed3f,2002]describestheexploitationoftheTCPchecksumforperformingsuchactions.
As there are internet routers known to not check the IP Header Checksum,andthere
mightalsobemiddle-boxes(NATs,rewalls,etc.)notcheckingtheIPchecksumallegedly
duetoperformancereasons,similarmaliciousactivitytotheonedescribedin[Ed3f,2002]
might be performed with the IP checksum.
3.11 Source Address
The Source AddressofanIPdatagramidentiesthenodefromwhichthepacket
originated.
Strictlyspeaking,theSource AddressofanIPdatagramidentiestheinterfaceofthe
sendingsystemfromwhichthepacketwassent,(ratherthantheoriginating“system”),asin
the Internet Architecture there’s no concept of “node”.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 22/63
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/egresslteringintheinternetrouters.[NISCC,
2006]isadetailedguideoningressandegressltering.[BakerandSavola,2004]and
[FergusonandSenie,2000]discussingressltering.[GIAC,2000]discussesegress
ltering.
Evenwhentheobviouseldonwhichtoperformchecksforingress/egresslteringisthe
Source Address and Destination AddresseldsoftheIPheader,thereareother
occurrences of IP addresses on which the same type of checks should be performed. One
exampleistheIPaddressescontainedinthepayloadofICMPerrormessages,asdiscussedin[Gont,2008]and[Gont,2006].
There are a number of sanity checks that should be performed on the Source Address
ofanIPdatagram.DetailscanbefoundinSection4.2(“Addressing”).
Additionally,therearefreelyavailabletoolsthatallowadministratorstomonitorwhichIP
addressesareusedwithwhichMACaddresses[LBNL/NRG,2006].Thisfunctionalityis
alsoincludedinmanyNetworkIntrusionDetectionSystems(NIDS).
It is also very important to understand that authentication should never rely on the Source
Address of the communicating systems.
3.12 Destination Address
The Destination AddressofanIPdatagramidentiesthedestinationhosttowhichthe
packet is meant to be delivered.
Strictlyspeaking,theDestination AddressofanIPdatagramidentiestheinterfaceof
thedestinationnetworkinterface,ratherthanthedestination“system”.AsintheInternet
Architecture there is no concept of “node”.
There are a number of sanity checks that should be performed on the Destination
AddressofanIPdatagram.DetailscanbefoundinSection4.2(“Addressing”).
3.13 Options
AccordingtoRFC791,IPoptionsmustbeimplementedbyallIPmodules,bothinhosts
andgateways(i.e.,end-systemsandintermediate-systems).
There are two cases for the format of an option:
• Case : A single byte of option-type.• Case 2: An option-typebyte,anoption-lengthbyte,andtheactualoption-data
bytes.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 23/63
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-typehasthreeelds:
• bit: copied ag.
• 2 bits: option class.
• 5 bits: option number.
The copied ag indicates whether this option should be copied to all fragments when the
packet carrying it needs to be fragmented:
• 0 = not copied.
• = copied.
The values for the option class are:
• 0 = control.
• = reserved for future use.
• 2 = debugging and measurement.
• 3 = reserved for future use.
ThisformatallowsforthecreationofnewoptionsfortheextensionoftheIP.
Finally,theoption numberidentiesthesyntaxoftherestoftheoption.
3.13.1 General issues with IP options
The following subsections discuss security issues that apply to all IP options.
Theproposedchecksshouldbeperformedinadditiontoanyoption-specic
checksproposedinthenextsections.
3.13.1.1 Processing requirements
Router manufacturers tend to do IP option processing on the main processor
rather than on line cards. Unless special care is taken this may be a security
risk as there is potential for overwhelming the router with option processing.
Toreducetheimpactofthesepacketsonthesystemperformance,afew
counter-measurescouldbeimplemented:
• Rate-limitthenumberofpacketswithIPoptionsthatareprocessedby
the system.
• Enforcealimitonthemaximumnumberofoptionstobeacceptedonagiven internet datagram.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 24/63
22
Security Assessment of the Internet Protocol
TherstcheckavoidsaowofpacketswithIPoptionstooverwhelmthe
system in question. The second check avoids packets with multiple IP options
to affect the performance of the system.
3.13.1.2 Processing of the options by the upper layer protocol
Section3.2.1.8ofRFC1122[Braden,1989]statesthatalltheIPoptions
received in IP datagrams must be passed to the transport layer (or to ICMP
processing when the datagram is an ICMP message). Care in option
processing must be taken not only at the internet layer but also in every
protocol module that may end up processing the options included in an IP
datagram.
3.13.1.3 General sanity checks on IP options
There are a number of sanity checks that should be performed on IP options
before further option processing is done. They help prevent a number of
potentialsecurityproblemsincludingbufferoverows.Whenthesechecksfail
the packet carrying the option should be dropped.
RFC1122[Braden,1989]recommendstosendanICMP“Parameter
Problem” message to the originating system when a packet is dropped
becauseofainvalidvalueinaeld,suchasthecasesdiscussedinthe
following subsections. Sending such a message might help in debugging
some network problems. However it would also alert attackers about the
system that is dropping packets because of the invalid values in the protocolelds.
We advise that systems default to sending an ICMP “Parameter Problem”
error message when a packet is dropped because of an invalid value in a
protocoleld(e.g.asaresultofdroppingapacketduetothesanitychecks
described in this section). However we recommend that systems provide a
system-widetogglethatallowsanadministratortooverridethedefault
behavior so that packets can be silently dropped when an invalid value in a
protocoleldisencountered.
Option length
Section3.2.1.8ofRFC1122explicitlystatesthattheIPlayermustnotcrash
astheresultofanoptionlengththatisoutsidethepossiblerange,and
mentions that erroneous option lengths have been observed to put some IP
implementationsintoinniteloops.
Foroptionsthatbelongtothe“Case2”describedintheprevioussection,the
following check should be performed:
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 25/63
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-offsetistheoffsetoftherstbyteoftheoptionwithintheIP
header,withtherstbyteoftheIPheaderbeingassignedanoffsetof0.
Ifapacketdoesnotpassbothofthesechecks,itshouldbedropped.
The aforementioned check is meant to detect forged option-length values
that might make an option overlap with the IP payload. This would be
particularly dangerous for those IP options which request the processing
systemstowriteinformationintotheoption-dataarea(suchastheRecord
Routeoption),asitwouldallowthegenerationofoverows.
Data types
ManyIPoptionsusepointerandlengthelds.Caremustbetakenastothe
datatypeusedfortheseeldsintheimplementation.Forexample,ifan8-bit
signeddatatypewereusedtoholdan8-bitpointer,thenpointervalueslarger
than 28 might mistakenly be interpreted as negative numbers and might lead
to unpredictable results.
3.13.2 Issues with specic options
3.13.2.1 End of Option List (Type = 0)
This option is used to indicate the “end of options” in those cases in which
the end of options would not coincide with the end of the Internet Protocol
Header.
IP systems are required to ignore those options they do not implement.
Therefore,eveninthosecasesinwhichthisoptionisrequired,butismissing,
IP systems should be able to process the remaining bytes of the IP header
without any problems.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 26/63
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:
• Bypassrewallrules
• Reach otherwise unreachable internet systems
• Establish TCP connections in a stealthy way
• Learn about the topology of a network • Performbandwidth-exhaustionattacks
Oftheseattackvectors,theonethathasprobablyreceivedleastattentionis
theuseoftheLSRRoptiontoperformbandwidthexhaustionattacks.The
LSRRoptioncanbeusedasanamplicationmethodforbandwidth-
exhaustionattacksasanattackercouldmakeapacketbouncemultipletimes
between a number of systems by carefully crafting an LSRR option.
ThisistheIPv4-versionoftheIPv6amplicationattackthatwaswidely
publicisedin2007[BiondiandEbalard,2007].Theonlydifferenceisthatthe
maximumlengthoftheIPv4header(andhencetheLSRRoption)limitstheamplicationfactorwhencomparedtotheIPv6counter-part.
WhiletheLSSRoptionmaybeofhelpindebuggingsomenetworkproblems,
its security implications outweigh any legitimate use.
Allsystemsshould,bydefault,dropIPpacketsthatcontainanLSRRoption.
However,theyshouldprovideasystem-widetoggletoenablesupportforthis
optionforthosescenarioswhereoptionisrequired.Suchasystem-wide
toggle should default to “off” (or “disable”).
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 27/63
25
Security Assessment of the Internet Protocol
[OpenBSD,1998]isasecurityadvisoryaboutanimproperimplementationof
suchasystem-widetogglein4.4BSDkernels.
Section3.3.5ofRFC1122[Braden,1989]statesthatahostmaybeableto
actasanintermediatehopinasourceroute,forwardingasource-routeddatagramtothenextspeciedhop.Westronglydiscouragehostsoftware
fromforwardingsource-routeddatagrams.
Ifprocessingofsource-routeddatagramsisexplicitlyenabledinasystem,the
following sanity checks should be performed.
RFC791statesthatthisoptionshouldappear,atmost,onceinagiven
packet.If a packet is found to have more than one LSRR option it should be
dropped.Therefore,hostsandroutersshoulddiscardpacketsthatcontain
morethanoneLSRRoption.Additionally,ifapacketwerefoundtohaveboth
LSRR and SSRR options it should be dropped.
AsmanyotherIPoptionstheLSSRcontainsaLengtheldthatindicatesthe
lengthoftheoption.GiventheformatoftheoptiontheLengtheldshouldbe
checked to be at least 3 (three):
LSRR.Length>=3
If the packet does not pass this check it should be dropped.
Additionally,thefollowingcheckshouldbeperformedontheLengtheld:
LSRR.Offset + LSRR.Length < IHL *4
ThischeckassuresthattheoptiondoesnotoverlapwiththeIPpayload(i.e.,
it does not go past the IP header). If the packet does not pass this check it
should be dropped.
The Pointerisrelativetothisoption.Thus,theminimumlegalvalueis4.
Therefore,thefollowingcheckshouldbeperformed.
LSRR.Pointer>=4
Ifthepacketdoesnotpassthischeckitshouldbedropped.Additionally,the
Pointereldshouldbeamultipleof4.Consequently,thefollowingcheck
should be performed:
LSRR.Pointer % 4 == 0
If a packet does not pass this check it should be dropped.
WhenasystemreceivesanIPpacketwiththeLSRRrouteoption,itshould
check whether the source route is empty or not. The option is empty if:
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 28/63
26
Security Assessment of the Internet Protocol
LSRR.Pointer >LSRR.Length
In that case routing should be based on the Destination Addresseldand
no further processing should be done on the LSRR option.
[Microsoft,1999]isasecurityadvisoryaboutavulnerabilityarisingfrom
improper validation of the LSRR.Pointereld.
If the address in the Destination Addresseldhasbeenreached,andthe
optionisnotempty,thenextaddressinthesourceroutereplacestheaddress
in the Destination Addresseld.
The IP address of the interface that will be used to forward this datagram
shouldberecordedintotheLSRR.However,beforewritingintheroute data
area,thefollowingcheckshouldbeperformed:
LSRR.Length – LSRR.Pointer>=3
This assures that there will be at least 4 bytes of space in which to record the
IP address. If the packet does not pass this check it should be dropped.
Anoffsetof“1”correspondstotheoptiontype,that’swhytheperformed
checkisLSRR.Length–LSRR.Pointer>=3,andnotLSRR.Length–LSRR.
Pointer>=4.
The LSRR must be copied on fragmentation. This means that if a packet that
carriestheLSRRisfragmented,eachofthefragmentswillhavetogothroughthelistofsystemsspeciedintheLSRRoption.
3.13.2.4 Strict Source and Record Route (SSRR) (Type = 137)
This option allows the originating system to specify a number of intermediate
systems a packet must pass through to get to the destination host.
Additionally,theroutefollowedbythepacketisrecordedintheoption,and
thedestinationhost(end-system)mustusethereverseofthepathcontained
in the received SSRR option.
This is similar to the LSRR option with the only difference that in the case of
SSRRtheroutespeciedintheoptionistheexactroutethepacketmusttake
(i.e.,nootherinterveningroutersareallowedtobeintheroute).
The SSSR option can be of help in debugging some network problems. Some
ISP Internet Service Provider) peering agreements require support for this
option in the routers within the peer of the ISP.
TheSSRRoptionhaswell-knownsecurityimplications.Amongotherthings,
the option can be used to:
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 29/63
27
Security Assessment of the Internet Protocol
• Bypassrewallrules
• Reach otherwise unreachable internet systems
• Establish TCP connections in a stealthy way
• Learn about the topology of a network
• Performbandwidth-exhaustionattacks
Oftheseattackvectors,theonethathasprobablyreceivedleastattentionis
theuseoftheSSRRoptiontoperformbandwidthexhaustionattacks.The
SSRRoptioncanbeusedasanamplicationmethodforbandwidth-
exhaustionattacksasanattackercouldmakeapacketbouncemultipletimes
between a number of systems by carefully crafting an LSRR option.
ThisistheIPv4-versionoftheIPv6amplicationattackthatwaswidely
publicisedin2007[BiondiandEbalard,2007].Theonlydifferenceisthatthe
maximumlengthfortheIPv4header(andhencetheSSRRoption)limitsthe
amplicationfactorwhencomparedtotheIPv6counter-part.
While the SSSR option may be of help in debugging some network problems
its security implications outweigh any legitimate use of it.
Allsystemsshould,bydefault,dropIPpacketsthatcontainanLSRRoption.
However,theyshouldprovideasystem-widetoggletoenablesupportforthis
optionforthosescenariosinwhichthisoptionisrequired.Suchsystem-wide
toggle should default to “off” (or “disable”).
[OpenBSD,1998]isasecurityadvisoryaboutanimproperimplementationof
suchasystem-widetogglein4.4BSDkernels.
ShouldprocessingoftheSSRRoptionbeexplicitlyenabledtherearesome
sanity checks that should be performed.
RFC791statesthatthisoptionshouldappear,atmost,onceinagiven
packet.Thus,ifapacketisfoundtohavemorethanoneSSRRoptionit
shouldbedropped.Also,ifapacketcontainsacombinationofSSRRand
LSRR options it should be dropped.
As the SSRR option is meant to specify the route a packet should follow from
sourcetodestination,useofmorethanoneSSRRoptioninasinglepacket
would be nonsensical. Therefore hosts and routers should check the IP
header and discard the packet if it contains more than one SSRR option or a
combination of LSRR and SSRR options.
As with many other IP options the SSRR option contains a Lengtheldthat
indicatesthelengthoftheoption.Thelengtheldshouldbecheckedtobeat
least 3:
SSRR.Length>=3
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 30/63
28
Security Assessment of the Internet Protocol
If the packet does not pass this check it should be dropped.
Additionally,thefollowingcheckshouldbeperformedonthelengtheld:
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 Pointereldisrelativetothisoption,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,thePointereldshouldbeamultipleof4.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 IPaddresses.Ifdoesnot,itshouldbedropped.
ContrarytotheIPLooseSourceandRecordRoute(LSRR)option,theSSRR
option does not allow in the route other routers than those contained in theoption.Ifthesystemimplementstheweakend-systemmodelitisallowedfor
the system to receive a packet destined to any of its IP addresses on any of itsinterfaces.Ifthesystemimplementsthestrongend-systemmodelapacket
destined to it can be received only on the interface that corresponds to the IPaddress contained in the Destination Addresseld[Braden,1989].
If the packet passes this check the receiving system should determine
whether the source route is empty or not. The option is empty if:
SSRR.Pointer>SSRR.Length
Inthatcase,iftheaddressinthedestinationeldhasnotbeenreachedthe
packet should be dropped.
[Microsoft,1999]isasecurityadvisoryaboutavulnerabilityarisingfrom
improper validation of the SSRR.Pointereld.
Iftheoptionisnotempty,andtheaddressintheDestination Address eld
hasbeenreached,thenextaddressinthesourceroutereplacestheaddress
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 31/63
29
Security Assessment of the Internet Protocol
in the Destination Addresseld.ThisIPaddressmustbereachablewithout
theuseofanyinterveningrouter(i.e.,theaddressmustbelongtoanyofthe
networks to which the system is directly attached). If that is not the case the
packet should be dropped.
The IP address of the interface that will be used to forward this datagram
shouldberecordedintotheSSRR.However,beforedoingthat,thefollowing
check should be performed:
SSRR.Length – SSRR.Pointer>=3
Anoffsetof“1”correspondstotheoptiontype,that’swhytheperformed
check is SSRR.Length – SSRR.Pointer>=3,andnotSSRR.Length –SSRR.Pointer >=4.
This assures that there will be at least 4 bytes of space on which to record theIP address. If the packet does not pass this check it should be dropped.
The SSRR option must be copied on fragmentation. This means that if a
packetthatcarriestheSSRRisfragmented,eachofthefragmentswillhave
togothroughthelistofsystemsspeciedintheSSRRoption.
3.13.2.5 Record Route (Type = 7)
This option provides a means to record the route that a given packet follows.
Theoptionbeginswithan8-bitoptioncodewhichmustbeequalto7.The
secondbyteistheoptionlength,whichincludestheoption-typebyte,the
option-lengthbyte,thepointer byte,andtheactualoption-data. The third
byteisapointerintotheroutedata,indicatingtherstbyteoftheareain
whichtostorethenextroutedata.Thepointerisrelativetotheoptionstart.
RFC791statesthatthisoptionshouldappearonce,atmost,inagiven
packet.Therefore,ifapackethasmorethanoneinstanceofthisoptionit
should be dropped.
Giventheformatoftheoption,theLengtheldshouldbecheckedtobeatleast 3:
RR.Length>=3
If the packet does not pass this check it should be dropped.
Additionally,thefollowingcheckshouldbeperformedontheLengtheld:
RR.Offset + RR_Length < IHL *4
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 32/63
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.
Thepointereldisrelativetothisoption,withtheminimumlegalvaluebeing4. Therefore the following check should be performed:
RR.Pointer >=4
If the packet does not pass this check it should be silently dropped.
Additionally,thePointer eldshouldbeamultipleof4.Consequently,the
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,thefollowingcheckshouldbeperformedbefore writing any route data into the option:
RR.Length - RR.Pointer>=3
Anoffsetof“1”correspondstotheoptiontype,that’swhytheperformedcheckis
LSRR.Length – LSRR.Pointer>=3,andnotLSRR.Length – LSRR.Pointer >=4.
If the packet does not pass this check the packet should be considered in
error and therefore should be silently dropped.
Iftheoptionisnotfull(i.e.,RR.Pointer <= RR.Length),butRR.Length –RR.Pointer<3,itmeansthatwhilethere’sspaceintheoption,thereisnot
enough space to store an IP address. It is fair to assume that such a scenariowill only occur when the packet has been crafted.
If the packet passes this check the IP address of the interface that will be
used to forward this datagram should be recorded into the area pointed by
the RR.Pointer,andRR.Pointer should then be incremented by 4.
Thisoptionisnotcopiedonfragmentationandappearsintherstfragment
only. If a fragment other than the one with offset 0 contains the Record Route
option it should be dropped.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 33/63
3
Security Assessment of the Internet Protocol
TheRecordRouteoptioncanbeexploitedtolearnaboutthetopologyofa
network,asitallowsanattackertorecord.
3.13.2.6 Stream Identier (Type = 136)
TheStreamIdentieroptionoriginallyprovidedameansforthe16-bitSATNET
streamIdentiertobecarriedthroughnetworksthatdidnotsupportthe
stream concept.
However,asstatedbySection4.2.2.1ofRFC1812[Baker,1995],thisoption
is obsolete. Therefore it should be ignored by the processing systems.
Inthecaseoflegacysystemsstillusingthisoption,thelengtheldofthe
option should be checked to be 4. If the option does not pass this check it
should be dropped.
RFC 79 states that this option appears at most once in a given datagram. If
a packet contains more than one instance of this option it should be dropped.
3.13.2.7 Internet Timestamp (Type = 68)
This option provides a means for recording the time at which each system
processed this datagram. The timestamp option has a number of security
implications such as:
• It allows an attacker to obtain the current time of the systems thatprocessthepacket,whichtheattackermayndusefulinanumberof
scenarios.
• Itmaybeusedtomapthenetworktopology,inasimilarwaytotheIP
Record Route option.
• Itmaybeusedtongerprinttheoperatingsysteminusebyasystem
processing the datagram.
• Itmaybeusedtongerprintphysicaldevices,byanalysingtheclock
skew.
Therefore,bydefault,thetimestampoptionshouldbeignored.
Forthosesystemsthathavebeenexplicitlyconguredtohonorthisoption,
the rest of this subsection describes some sanity checks that should be
enforced on the option before further processing.
The option begins with an option-type byte which must be equal to 68. The
second byte is the option-length which includes the option-typebyte,the
option-lengthbyte,thepointer and the overow/ag byte. The minimum
legalvaluefortheoption-lengthbyteis4,whichcorrespondstoanInternet
Timestamp option that is empty (no space to store timestamps). Therefore
upon receipt of a packet that contains an Internet Timestamp option thefollowing check should be performed:
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 34/63
32
Security Assessment of the Internet Protocol
IT.Length>=4
If the packet does not pass this check it should be dropped.
Thefollowingcheckshouldalsobeperformedontheoptionlengtheld:
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 pointerbytepointstotherstbyteoftheareainwhichthenext
timestamp data should be stored. As its value is relative to the beginning of
theoptionitsminimumlegalvalueis5.Consequently,thefollowingcheck
should be performed on a packet that contains the Internet Timestampoption:
IT.Pointer >=5
If the packet does not pass this check it should be dropped.
The ag eldhasthreepossiblelegalvalues:
• 0:Recordtimestampsonly,storedinconsecutive32-bitwords.
• : Record each timestamp preceded with the internet address of the
registering entity.
• 3:Theinternetaddresseldsoftheoptionarepre-specied.AnIP
module only registers its timestamp if it matches its own address with
thenextspeciedinternetaddress.
Therefore the following check should be performed:
IT.Flag == 0 || IT.Flag == || IT.Flag == 3
If the packet does not pass this check it should be dropped.
The timestampeldisaright-justied32-bittimestampinmillisecondssince
UT.Ifthetimeisnotavailableinmilliseconds,orcannotbeprovidedwith
respecttoUT,thenanytimemaybeinsertedasatimestamp,providedthe
highorderbitofthetimestampisset,toindicatethisnon-standardvalue.
AccordingtoRFC791,theinitialcontentsofthetimestampareamustbe
initialisedtozero,orinternetaddress/zeropairs.However,internetsystems
shouldbeabletohandlenon-zerovaluespossiblydiscardingtheoffending
datagram.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 35/63
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,theoverowbyteshouldbeincremented,
and the packet should be forwarded without inserting the timestamp. If the
overowbyteitselfoverowsthepacketshouldbedropped.
If timestamp data area is not full further checks should be performed before
actually inserting any data.
• If the IT.Flag byte is 0 the following check should be performed:
IT.Length – IT.Pointer >=3
If the packet does not pass this check it should be dropped. If the packet
passesthischeckthereisroomforatleastone32-bittimestamp.The
system’s32-bittimestampshouldbeinsertedattheareapointedbythe
pointerbyte,andthepointerbyteshouldbeincrementedbyfour.
• If the IT.Flag byte is then the following check should be performed:
IT.Length–IT.Pointer>=7
If the packet does not pass this check it should be dropped. If the packet
does pass this check it means there is space in the timestamp data area to
storeatleastoneIPaddressplusthecorresponding32-bittimestamp.TheIP
address of the system should be stored at the area pointed to by the pointer
byte,followedbythe32-bitsystemtimestamp.Thepointerbyteshouldthen
be incremented by 8.
• Iftheagbyteis3thenthefollowingcheckshouldbeperformed:
IT.Length – IT.Pointer>=7
If the packet does not pass this check it should be dropped. If it does it
means there is space in the timestamp data area to store an IP address and
storethecorresponding32-bittimestamp.Thesystem’stimestampshouldbe
stored at the area pointed by IT.Pointer + 4. The pointer byte should be
incremented by 8.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 36/63
34
Security Assessment of the Internet Protocol
[Kohnoetal,2005]describesatechniqueforngerprintingdevicesby
measuringtheclockskew.Itexploits,amongotherthings,thetimestamps
that can be obtained by means of the ICMP timestamp request messages
[Postel,1981].Thesamengerprintingmethodcouldbeimplementedwith
the aid of the Internet Timestamp option.
3.13.2.8 Router Alert (Type = 148)
TheRouterAlertoptionisdenedinRFC2113[Katz,1997].Ithasthe
semantic“routersshouldexaminethispacketmoreclosely”.Apacketthat
containsaRouterAlertoptionwillnotgothroughtherouter’sfast-pathand
will be processed in the router more slowly than if the option were not set.
Therefore this option may impact the performance of the systems that handle
the packet carrying it.
AccordingtothesyntaxoftheoptionasdenedinRFC2113,thefollowing
check should be enforced:
RA.Length == 4
Ifthepacketdoesnotpassthischeckitshouldbedropped.Furthermore,the
following check should be performed on the Valueeld:
RA.Value == 0
If the packet does not pass this check it should be dropped.
AsexplainedinRFC2113hostsshouldignorethisoption.
3.13.2.9 Probe MTU (Type =11)
ThisoptionisdenedinRFC1063[Moguletal,1988]andoriginallyprovided
amechanismtodiscoverthePath-MTU.
This option is obsolete and therefore any packet that is received containing
this option should be dropped.
3.13.2.10 Reply MTU (Type = 12)
ThisoptionisdenedinRFC1063[Moguletal,1988]andoriginallyprovided
amechanismtodiscoverthePath-MTU.
This option is obsolete and therefore any packet that is received containing
this option should be dropped.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 37/63
35
Security Assessment of the Internet Protocol
3.13.2.11 Traceroute (Type = 82)
ThisoptionisdenedinRFC1393[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 authorities indicated on the datagram.
ItisspeciedbyRFC1108[Kent,1991](whichobsoletesRFC1038[St.
Johns,1988]).
RFC791[Postel,1981]denedthe“SecurityOption”(Type=130),which
usedthesameoptiontypeastheDoDBasicSecurityoptiondiscussedinthis
section.The“SecurityOption”speciedinRFC791isconsideredobsoleteby
Section4.2.2.1ofRFC1812,andthereforethediscussioninthissectionis
focusedontheDoDBasicSecurityoptionspeciedbyRFC1108[Kent,
1991].
Section4.2.2.1ofRFC1812statesthatrouters“SHOULDimplementthis
option”.
TheDoDBasicSecurityOptioniscurrentlyimplementedinanumberof
operatingsystems(e.g.[IRIX,2008],[SELinux,2008],[Solaris,2008],and
[Cisco,2008]),anddeployedinanumberofhigh-securitynetworks.
RFC 08 states that the option should appear once in a datagram at the
most.IfmorethanoneDoDBasicSecurityoption(BSO)appearsinagiven
datagram the corresponding datagram should be dropped.
RFC 08 states that the option Length is variable with a minimum option
Length of 3 bytes. Therefore the following check should be performed:
BSO.Length>=3
If the packet does not pass this check it should be dropped.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 38/63
36
Security Assessment of the Internet Protocol
Systems that belong to networks in which this option is in use should process
theDoDBasicSecurityoptioncontainedineachpacketasspeciedin[Kent,
1991].
CurrentdeploymentsoftheDoDSecurityOptionshavemotivatedtheproposalof a “Common Architecture Label IPv6 Security Option (CALIPSO)” for the IPv6protocol.[St.Johnsetal,2008].
3.13.2.13 DoD Extended Security Option (Type = 133)
Thisoptionpermitsadditionalsecuritylabelinginformation,beyondthat
presentintheBasicSecurityOption(Section3.13.2.12),tobesuppliedinan
IPdatagramtomeettheneedsofregisteredauthorities.ItisspeciedbyRFC
1108[Kent,1991].
ThisoptionmaybepresentonlyinconjunctionwiththeDoDBasicSecurityoption.ThereforeifapacketcontainsaDoDExtendedSecurityoption(ESO),
butdoesnotcontainaDoDBasicSecurityoption,itshouldbedropped.It
shouldbenotedthat,unliketheDoDBasicSecurityoption,thisoptionmay
appear multiple times in a single IP header.
RFC1108statesthattheoptionLengthisvariable,withaminimumoption
Length of 3 bytes. Therefore the following check should be performed:
ESO.Length>=3
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
theDoDExtendedSecurityoptioncontainedineachpacketasspeciedin
RFC1108[Kent,1991].
3.13.2.14 Commercial IP Security Option (CIPSO) (Type = 134)
This option was proposed by the Trusted Systems Interoperability Group
(TSIG) with the intent of meeting trusted networking requirements for the
commercialtrustedsystemsmarketplace.Itisspeciedin[CIPSO,1992]and[FIPS,1994].
The TSIG proposal was taken to the Commercial Internet Security Option(CIPSO)WorkingGroupoftheIETF[CIPSOWG,1994],andanInternet-Draft
wasproduced[CIPSO,1992].TheInternet-Draftwasneverpublishedasan
RFC,andtheproposalwaslaterstandardisedbytheU.S.NationalInstituteof
Standards and Technology (NIST) as “Federal Information Processing StandardPublication188”[FIPS,1994].
Itiscurrentlyimplementedinanumberofoperatingsystems(e.g.IRIX[IRIX,
2008],Security-EnhancedLinux[SELinux,2008],andSolaris[Solaris,2008])
anddeployedinanumberofhigh-securitynetworks.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 39/63
37
Security Assessment of the Internet Protocol
[ZakrzewskiandHaddad,2002]and[HaddadandZakrzewski,2004]provide
anoverviewofaLinuximplementation.
Accordingtotheoptionsyntaxspeciedin[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
theCIPSOoptioncontainedineachpacketasspeciedin[CIPSO,1992].
3.13.2.15 Sender Directed Multi-Destination Delivery (Type = 149)
ThisoptionisdenedinRFC1770[Graff,1995],andoriginallyprovidedunreliableUDPdeliverytoasetofaddressesincludedintheoption.
This option is obsolete. If a received packet contains this option it should be
dropped.
3.14 Differentiated Services eld
TheDifferentiatedServicesArchitectureisintendedtoenablescalableservice
discriminationintheInternetwithouttheneedforper-owstateandsignalingateveryhop
[Blakeetal,1998].RFC2474[Nicholsetal,1998]denesaDifferentiated Services Field (DSField),whichisintendedtosupersedetheoriginalType of Serviceeld.Figure
4showstheformatoftheeld.
Figure5:StructureoftheDSField
The DSCP (“Differentiated Services CodePoint”) is used to select the treatment the
packetistoreceivewithintheDifferentiatedServicesDomain.TheCU (“Currently
Unused”)eldwas,atthetimethespecicationwasissued,reservedforfutureuse.The
DSCPeldisusedtoselectaPHBbymatchingagainsttheentire6-biteld.
Considering that the DSCPelddetermineshowapacketistreatedwithinaDSdomain,
an attacker sends packets with a forged DSCPeldtoperformatheftofserviceoreven
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 40/63
38
Security Assessment of the Internet Protocol
aDenialofServiceattack.Inparticular,anattackercouldforgepacketswithacodepoint
ofthetype‘11x000’which,accordingtoSection4.2.2.2ofRFC2474[Nicholsetal,
1998],wouldgivethepacketspreferentialforwardingtreatmentwhencomparedwiththe
PHBselectedbythecodepoint‘000000’.Ifstrictpriorityqueuingwereutilised,a
continuousstreamofsuchpocketscouldperformaDenialofServicetootherowswhichhave a DSCP of lower relative order.
As the DSeldisincompatiblewiththeoriginalType of Serviceeld,bothDSdomains
and networks using the original Type of Serviceeldshouldprotectthemselvesbyre-
markingthecorrespondingeldwhereappropriate,probablydeployingremarking
boundary nodes. Care must be taken so that packets received with an unrecognised
DSCP do not cause the handling system to malfunction.
3.15 Explicit Congestion Notication (ECN)
RFC3168[Ramakrishnanetal,2001]speciesamechanismforrouterstosignal
congestiontohostssendingIPpacketsbymarkingtheoffendingpackets,ratherthan
discardingthem.RFC3168denestheECNeldwhichutilisestheCUunusedeldof
the DSCPelddescribedinSection3.14ofthisdocument.Figure5showsthesyntaxof
the ECNeld,togetherwiththeDSCPeldusedforDifferentiatedServices.
Figure6:TheDifferentiatedServicesandECNeldsinIP
Assuch,theECNelddenesfourcodepoints:
ECN eld Codepoint
00 Not-ECT
0 ECT()
0 ECT(0) CE
The security implications of ECN are discussed in detail in a number of Sections of RFC
3168.OfthepossiblethreatsdiscussedintheECNspecicationwebelievethatonethat
canbeeasilyexploitedisthehostfalselyindicatingECN-Capability.
An attacker could set the ECT codepoint in the packets it sends to signal the network that
theendpointsofthetransportprotocolareECN-capable.Consequently,when
experiencingmoderatecongestion,routersusingactivequeuemanagementbasedon
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 41/63
39
Security Assessment of the Internet Protocol
REDwouldmarkthepackets(withtheCEcodepoint)ratherthandiscardthem.Inthe
samescenario,packetsofcompetingowsthatdonothavetheECTcodepointset
would be dropped. Therefore an attacker would get better network service than the
competingows.
However if this moderate congestion turned into heavy congestion routers should switch
todroppackets,regardlessofwhetherthepacketshavetheECTcodepointsetornot.
A number of other threats could arise if an attacker was a man in the middle (i.e. was in
the middle of the path the packets travel to get to the destination host). For a detailed
discussionofthosecases,weurgethereadertoconsultSection16ofRFC3168.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 42/63
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),bypassingrewallrules,andperformingDenialofService(DoS)attacks.
[Bendi1998]and[Humble,1998]areexamplesoftheexploitationoftheseissuesfor
performingDenialofService(DoS)attacks.[CERT,1997]and[CERT,1998b]document
theseissues.[Anderson,2001]isasurveyoffragmentationattacks.[US-CERT,2001]isan
exampleoftheexploitationofIPfragmentationtobypassrewallrules.[CERT,1999]
describestheimplementationoffragmentationattacksinDistributedDenialofService
(DDoS)attacktools.
ThebasicproblemwithIPfragmentreassemblyisthecomplexityofthefunctionina
number of aspects:
• Fragment reassembly is a stateful operation for a stateless protocol (IP). The IPmodule at the host performing the reassembly function must allocate memory
buffers both for temporarily storing the received fragments and to perform the
reassemblyfunction.Attackerscanexploitthisfacttoexhaustmemorybuffersat
the system performing the fragment reassembly.
• The fragmentation and reassembly mechanisms were designed at a time in which
the available bandwidths were very different from the bandwidths available now.
With the currently available bandwidths a number of interoperability problems may
ariseandtheseissuesmaybeintentionallyexploitedbyattackerstoperformDenial
ofService(DoS)attacks.
• Fragment reassembly must usually be performed without any knowledge of the
properties of the path the fragments follow. Without this information hosts cannot
make any educated guess on how long they should wait for missing fragments to
arrive.
• Thefragmentreassemblyalgorithm,asdescribedbytheIETFspecicationsis
ambiguousandallowsforanumberofinterpretations,eachofwhichhasfound
placeindifferentTCP/IPstackimplementations.
• Thereassemblyprocessissomewhatcomplex.Fragmentsmayarriveoutoforder,duplicated,overlapping,etc.andthiscomplexityhasleadtonumerousbugsin
different implementations of the IP protocol.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 43/63
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
specicationsrecommendtowaitforaperiodoftimethatwillbeacceptable
for virtually all the possible network scenarios in which the protocols might
operate.Specically,RFC1122[Braden,1989]statesthatthereassembly
timeoutshouldbeaxedvaluebetween60and120seconds.Ifafterwaiting
forthatperiodoftimetheremainingfragmentshavenotyetarrived,allthe
received fragments for the corresponding packet are discarded.
TheoriginalIPSpecication,RFC791[Postel,1981],statesthatsystems
should wait for at least 5 seconds for the missing fragments to arrive.Systemsthatfollowthe“ExampleReassemblyProcedure”describedin
Section 3.2 of RFC 79 may end up using a reassembly timer of up to 4.25minutes,withminimumof15seconds.Section3.3.2(“Reassembly”)ofRFC
1122correctedthisadvice,statingthatthereassemblytimeoutshouldbea
xedvaluebetween60and120seconds.
However,thelongerthesystemwaitsforthemissingfragmentstoarrive,the
longer the corresponding system resources must be tied to the corresponding
packet.Theamountofsystemmemoryisniteandevenwithtoday’ssystems
it can still be considered a scarce resource.
An attacker could take advantage of the uncomfortable situation the system
performing fragment reassembly is in by sending forged fragments that willneverreassembleintoacompletedatagram.Thatis,anattackerwouldsend
manydifferentfragments,withdifferentIPIDs,withouteversendingallthe
necessary fragments that would be needed to reassemble them into a full IP
datagram. For each of the fragments the IP module would allocate resources
and tie them to the corresponding fragment until the reassembly timer for the
correspondingpacketexpires.
There are some implementation strategies which could increase the impact of
thisattack.Forexample,uponreceiptofafragment,somesystemsallocatea
memory buffer that will be large enough to reassemble the whole datagram.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 44/63
42
Security Assessment of the Internet Protocol
Whilethismightbebenecialinlegitimatecases,thisjustampliestheimpact
ofthepossibleattacks,asasinglesmallfragmentcouldtieupmemory
buffersforthesizeofanextremelylarge(andunlikely)datagram.The
implementationstrategysuggestedinRFC815[Clark,1982]leadstosuchan
implementation.
The impact of the aforementioned attack may vary depending on some
specicimplementationdetails:
• If the system does not enforce limits on the amount of memory that can
be allocated by the IP module then an attacker could tie all system
memory to fragments at which point the system would become
unusable,probablycrashing.
• If the system enforces limits on the amount of memory that can be
allocated by the IP module as a whole then when this limit is reached allfurther IP packets that arrive would be discarded until some fragments
time out and free memory is available again.
• If the system enforces limits on the amount memory that can be
allocated for the reassembly of fragments (in addition to enforcing a
limitfortheIPmoduleasawhole)thenwhenthislimitisreached,all
further fragments that arrive would be discarded until some fragment(s)
time out and free memory is available again.
4.1.2 Problems that arise from the length of the IP Identication eld
The Internet Protocols are currently being used in environments that are quite
differentfromtheonesinwhichtheywereconceived.Forinstance,the
availability of bandwidth at the time the Internet Protocol was designed was
completely different from the availability of bandwidth in today’s networks.
The Identicationeldisa16-biteldthatisusedforthefragmentationand
reassemblyfunction.Intheeventadatagramgetsfragmented,allthe
corresponding fragments will share the same Identicationnumber.Thus,
the system receiving the fragments will be able to uniquely identify them as
fragments that correspond to the same IP datagram. At a given point in timethere must be at most only one packet in the network with a given
Identicationnumber.Ifnot,anIdentication number “collision” might
occurandthereceivingsystemmightendup“mixing”fragmentsthat
correspond to different IP datagrams which simply reused the same
Identication number.
For each group of fragments whose Identication numbers “collide” the
fragment reassembly will lead to corrupted packets. The IP payload of the
reassembled datagram will be handed to the corresponding upper layer
protocol,wheretheerrorwill(hopefully)bedetectedbysomeerrordetecting
code (such as the TCP checksum) and the packet will be discarded.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 45/63
43
Security Assessment of the Internet Protocol
Anattackercouldexploitthisfacttointentionallycauseasystemtodiscardall
orpartofthefragmentedtrafcitgets,thusperformingaDenialofService
attack.Suchanattackerwouldsimplyestablishaowoffragmentswith
differentIPIdenticationnumberstotrashallorpartoftheIPIdentication
space.Asaresult,thereceivingsystemwouldusetheattacker’sfragmentsforthereassemblyoflegitimatedatagrams,leadingtocorruptedpackets
which would later (and hopefully) get dropped.
Inmostcases,useofalongfragmenttimeoutwillbenettheattackeras
forgedfragmentswillkeeptheIPIdenticationspacetrashedforalonger
period of time.
4.1.3 Problems that arise from the complexity of the reassembly
algorithm
AsIPpacketscanbeduplicatedbythenetwork,andeachpacketmaytakea
differentpathtogettothedestinationhost,fragmentsmayarrivenotonlyout
oforderand/orduplicated,butalsooverlapping.Thismeansthatthe
reassemblyprocesscanbesomewhatcomplexwiththecorresponding
implementationbeingnotspecicallytrivial.
[Shannonetal,2001]analysesthecausesandattributesoffragmenttrafc
measured in several types of WANs.
Duringtheyears,anumberofattackshaveexploitedbugsinthereassembly
functionofanumberofoperatingsystems,producingbufferoverowsthathaveled,inmostcases,toacrashoftheattackedsystem.
4.1.4 Problems that arise from the ambiguity of the reassembly
process
NetworkIntrusionDetectionSystems(NIDSs)typicallymonitorthetrafcona
givennetworkwiththeintentofidentifyingtrafcpatternsthatmightindicate
network intrusions.
InthepresenceofIPfragments,inordertodetectillegitimateactivityatthe
transportorapplicationlayers(i.e.,anyprotocollayerabovethenetwork
layer),aNIDSmustperformIPfragmentreassembly.
Inordertocorrectlyassessthetrafc,theresultofthereassemblyfunction
performedbytheNIDSshouldbethesameasthereassemblyfunction
performed by the intended recipient of the packets.
However a number of factors make the result of the reassembly process
ambiguous:
• TheIETFspecicationsareambiguousastowhatshouldbedone
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 46/63
44
Security Assessment of the Internet Protocol
whenoverlappingfragmentswerereceived.Thus,inthepresenceof
overlappingdata,thesystemperformingthereassemblyfunctionisfree
toeitherhonortherstsetofdatareceived,thelatestcopyreceived,or
any other copy received in between.
• Asthespecicationsdonotenforceanyspecicfragmenttimeout
value,differentsystemsmaychoosedifferentvaluesforthefragment
timeout. This means that given a set of fragments received at some
speciedtimeintervalssomesystemswillreassemblethefragments
into a full datagram while others may timeout the fragments and
therefore drop them.
• AsthefragmentbuffersgetfullaDenialofService(DoS)conditionwill
occurunlesssomeactionistaken.Manysystemsushpartofthe
fragmentbufferswhensomethresholdisreached.Thus,dependingon
fragmentload,timingissuesandushingpolicy,aNIDSmayget
incorrect assumptions about how (and if) fragments are being
reassembled by their intended recipient.
Asoriginallydiscussedby[PtacekandNewsham,1998],theseissuescanbe
exploitedbyattackerstoevadeintrusiondetectionsystems.
ThereexistfreelyavailabletoolstoforcefullyfragmentIPdatagramstohelp
evadeIntrusionDetectionSystems.Fragrouter[Song,D.,1999]isan
exampleofsuchatool;itallowsanattackertoperformalltheevasion
techniquesdescribedin[PtacekandNewsham,1998].Ftester[Barisani,2006]isatoolthathelpstoauditsystemsregardingfragmentationissues.
4.1.5 Problems that arise from the size of the IP fragments
Oneapproachtofragmentlteringinvolveskeepingtrackoftheresultsof
applyinglterrulestotherstfragment(i.e.aFragment Offset of 0) and
applyingthemtosubsequentfragmentsofthesamepacket.Theltering
modulewouldmaintainalistofpacketsindexedbytheSource Address,
Destination Address,ProtocolandIdenticationnumber.Whentheinitial
fragmentisseen,iftheMFbitisset,alistitemwouldbeallocatedtoholdthe
resultoflteraccesschecks.Whenpacketswithanon-zeroFragmentOffsetcomein,lookupthelistelementwithamatchingSource Address/
Destination Address/Protocol/Identication and apply the stored result
(pass or block). When a fragment with a zero MFbitisseen,freethelist
element.Unfortunately,therulesofthistypeofpacketltercanusuallybe
bypassed.[Ziembaetal,1995]describesthedetailsoftheinvolved
technique.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 47/63
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 48/63
46
Security Assessment of the Internet Protocol
fragments,andthosethataimtocauseacollisionofIPIdentication
numbers,thereareanumberofcounter-measuresthatcanbeimplemented.
The IP module should enforce a limit on the amount of memory that can be
allocatedforIPfragments,aswellasalimitonthenumberoffragmentsthatwill be allowed in the system at any time. This will basically limit the resources
spentonthereassemblyprocess,andpreventanattackerfromtrashingthe
whole system memory.
Additionally,theIPmoduleshouldkeepadifferentbufferforIPfragmentsthan
for complete IP datagrams. This will basically separate the effects of fragment
attacksonnon-fragmentedtrafc.MostTCP/IPimplementations,suchas
thatinLinuxandthoseinBSD-derivedsystems,alreadyimplementthis.
Evenwiththesecounter-measuresinplacethereisstilltheissueofwhatto
dowhenthebufferusedforIPfragmentsgetfull.Basically,ifthefragment
bufferisfull,noinstanceofcommunicationthatreliesonfragmentationwillbe
able to progress.
Unfortunately there are not many options for reacting to this situation. If
nothing is done all the instances of communication that rely on fragmentation
willexperienceadenialofservice.Thus,theonlythingthatcanbedoneis
ushallorpartofthefragmentbufferonthepremisethatlegitimatetrafcwill
beabletomakeuseofthefreedbufferspacetoallowcommunicationows
to progress.
There are a number of factors that should be taken into consideration when
ushingthefragmentbuffer.First,ifafragmentofagivenpacket(i.e.,
fragment with a given Identicationnumber)isushed,alltheother
fragmentsthatcorrespondtothesamedatagramshouldbeushed.Asin
order for a packet to be reassembled all of its fragments must be received by
the system performing the reassembly function. Flushing only a subset of the
fragments of a given packet would keep the corresponding buffers tied to
fragments that would never reassemble into a complete datagram. Care
mustbetakensothat,intheeventthatsubsequentbufferushesneedtobe
performed,itisnotalwaysthesamesetoffragmentsthatgetdroppedas
suchabehaviorwouldprobablycauseaselectiveDenialofService(DoS)tothetrafcowstowhichthatsetoffragmentsbelong.
ManyTCP/IPimplementationsdeneathresholdforthenumberoffragments
that,whenreached,triggerafragment-bufferush.Somesystemsush1/2
ofthefragmentbufferwhenthethresholdisreached.Asmentionedbefore,
this is to create some free space in the fragment buffer on the premise that
this will allow for new and legitimate fragments to be processed by the IP
module,thuslettingcommunicationsurvivetheoverwhelmingsituation.On
theotherhand,theideaofushingasomewhatlargeportionofthebufferis
toavoidushingalwaysthesamesetofpackets.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 49/63
47
Security Assessment of the Internet Protocol
A more selective fragment buffer ushing strategy
Oneofthedifcultiesinimplementingcounter-measuresforthefragmentation
attacksdescribedinthisdocumentisthatitisdifculttoperformvalidation
checksonthereceivedfragments.Forinstance,thefragmentonwhichvaliditycheckscouldbeperformed,therstfragment,maybenottherst
fragment to arrive at the destination host.
Fragments can not only arrive out of order because of packet reordering
performedbythenetwork,butalsobecausethesystem(orsystems)that
fragmented the IP datagram may indeed transmit the fragments out of order.
AnotableexampleofthisistheLinuxTCP/IPstack,whichtransmitsthe
fragments in reverse order.
This means that we cannot enforce checks on the fragments for which we
allocatereassemblyresources,astherstfragmentwereceiveforagivenpacketmaybesomeotherfragmentthantherstone(theonewithan
Fragment Offset of 0).
However,whenwedecidetofreesomespaceinthefragmentbuffer,some
renementscanbedonetotheushingpolicy.Therstthingwewouldliketo
doistostopdifferenttypesoftrafcfrominterferingwitheachother.This
means,inprinciple,thatwedonotwantfragmentedUDPtrafctointerfere
withfragmentedTCPtrafc.Inordertoimplementthistrafcseparationfor
thedifferentprotocols,adifferentfragmentbufferwouldbeneeded,in
principle,foreachofthe256differentprotocolsthatcanbeencapsulatedin
an IP datagram.
We believe a tradeoff is to implement two separate fragment buffers: one for
IP datagrams that encapsulate IPsec packets and another for the rest of the
trafc.ThisbasicallymeansthattrafcnotprotectedbyIPsecwillnotinterfere
withthoseowsofcommunicationthatarebeingprotectedbyIPsec.
The processing of each of these two different fragment buffers would be
completely independent from each other. In the case of the IPsec fragment
buffer,whenthebufferneedstobeushedthefollowingrenedpolicycould
be applied:
• First,foreachpacketforwhichtheIPsecheaderhasbeenreceived
checkthattheSPIeldoftheIPsecheadercorrespondstoanexisting
IPsec Security Association (SA). And probably also check that the
IPsec sequence number is valid. If the check fails drop all the fragments
that correspond to this packet.
• Second,ifthefragmentbufferstillneedstobeusheddropallthe
fragments that correspond to packets for which the full IPsec header
has not yet been received. The number of packets for which this
ushingisperformeddependsontheamountoffreespacethatneedsto be created.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 50/63
48
Security Assessment of the Internet Protocol
• Third,ifthereisstillnotenoughspaceinthefragmentbufferafter
ushingpacketswithinvalidIPsecinformation(Firststep),andpackets
onwhichvalidationcheckscouldnotbeperformed(Secondstep),
drop all the fragments that correspond to packets that passed the
checksoftherststepuntilthenecessaryfreespaceiscreated.
Therationalebehindthispolicyisthat,atthepointofushingthefragment
buffer,weprefertokeepthosepacketsonwhichwecouldsuccessfully
perform a number of validation checks over those packets on which those
checksfailed,orcouldnotbeperformed.
BycheckingboththeIPsecSPIandtheIPsecsequencenumber,itisvirtually
impossibleforanattackerthatisoff-pathtoperformaDenialofServiceattack
tocommunicationowsbeingprotectedbyIPsec.
UnfortunatelysomeTCP/IPstacks,whenperformingfragmentation,sendthe
correspondingfragmentsinreverseorder.Insuchcases,atthepointof
ushingthefragmentbuffer,legitimatefragmentswillreceivethesame
treatment as the possible forged fragments.
Thisrenedushingpolicyprovidesanincreasedlevelofprotectionagainst
thistypeofresourceexhaustionattack,whilenotmakingthesituationofout-
of-orderIPsec-securedtrafcworsethanwiththesimpliedushingpolicy
described in the previous section.
Reducing the fragment timeout
RFC1122[Braden,1989]statesthatthereassemblytimeoutshouldbea
xedvaluebetween60and120seconds.Therationalebehindtheselong
timeout values is that they should accommodate any path characteristics
suchaslong-delaypaths.Howeveritmustbenotedthatthistimerisreally
measuringinter-fragmentdelays,ormorespecically,fragmentjitter.
Ifallfragmentstakepathsofsimilarcharacteristics,theinter-fragmentdelay
willusuallybeafewsecondsatmost.Nevertheless,eveniffragmentstake
different paths of different characteristics the recommended 60 to 20
secondsisexcessive.
Some systems have already reduced the fragment timeout to 30 seconds
[Linux,2006].Thefragmenttimeoutcouldprobablybefurtherreducedto
approximately15secondsalthoughfurtherresearchonthisissueis
necessary.
Itshouldbenotedthatinnetworkscenariosoflong-delayandhigh-
bandwidth(usuallyreferredtoas“Long-FatNetworks”),usingalongfragment
timeoutwouldlikelyincreasetheprobabilityofcollisionofIPIDnumbers.In
such scenarios it is mandatory to avoid the use of fragmentation with
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 51/63
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”
thatpreventsevasionofaNIDSbyacquiringsufcientknowledgeaboutthe
network being monitored to assess which packets will arrive at the intended
recipientandhowtheywillbeinterpretedbyit.[Novak,2005]describessome
techniquesthatareappliedbytheSnortNIDStoavoidevasion.
Counter-measure for rewall-rules bypassing
Oneoftheclassicaltechniquestobypassrewallrulesinvolvessending
packets in which the header of the encapsulated protocol is fragmented. Even
whenitwouldbelegal(asfarastheIETFspecicationsareconcerned)to
receivesuchpackets,theMTUsofthenetworktechnologiesusedinpractice
are not so small as to require the header of the encapsulated protocol to be
fragmented.Therefore,thesystemperformingreassemblyshoulddropall
packetswhichfragmenttheupper-layerprotocolheader.Thenecessary
information to perform this check could be stored by the IP module together
withtherestoftheupper-layerprotocolinformation.
Additionally,giventhatmanymiddle-boxessuchasrewallscreatestate
accordingtothecontentsoftherstfragmentofagivenpacket,itisbestthat
intheeventanend-systemreceivesoverlappingfragmentsithonorstheinformationcontainedinthefragmentthatwasreceivedrst.
RFC1858[Ziembaetal,1995]describestheabuseofIPfragmentationto
bypassrewallrules.RFC3128[Miller,2001]correctssomeerrorsinRFC
858.
4.2 Forwarding
4.2.1 Precedence-ordered queue service
Section5.3.3.1ofRFC1812[Baker,1995]statesthatroutersshould
implementprecedence-orderedqueueservice.Thismeansthatwhena
packetisselectedforoutputona(logical)link,thepacketofhighest
precedence that as been queued for that link is sent. Section 5.3.3.2 of RFC
1812advicesrouterstodefaulttomaintainingstrictprecedence-ordered
service.
GiventhatitistrivialtoforgetheIPprecedenceeldoftheIPheader,an
attacker could simply forge a high precedence number in the packets it sends
toillegitimatelygetbetternetworkservice.Ifprecedence-orderedqueued
service is not required in a particular network infrastructure it should be
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 52/63
50
Security Assessment of the Internet Protocol
disabledandallpacketswouldreceivethesametypeofservice,despitethe
values in their Type of Service or Differentiated Serviceselds.
WhenPrecedence-orderedqueueserviceisrequiredinthenetwork
infrastructure in order to mitigate the attack vector discussed in the previousparagraph,edgeroutersorswitchesshouldbeconguredtopoliceand
remark the Type of Service or Differentiated Services values according to
thetypeofserviceatwhicheachend-systemhasbeenallowedtosend
packets.
Bullet4ofSection5.3.3.3ofRFC1812statesthatrouters“MUSTNOT
changeprecedencesettingsonpacketsitdidnotoriginate”.However,given
thesecurityimplicationsofthePrecedenceelditisfairforrouters,switches
orothermiddle-boxes,particularlythoseinthenetworkedge,tooverwritethe
Type of Service (or Differentiated Services)eldofthepacketstheyare
forwardingaccordingtoacongurednetworkpolicy.
Section5.3.3.1andSection5.3.6ofRFC1812statesthatifprecedence-
ordered queue service is implemented and enabled the router “MUST NOT
discard a packet whose precedence is higher than that of a packet that is not
discarded”. While this recommendation makes sense given the semantics of
thePrecedenceeld,itisimportanttonotethatitwouldbesimpleforan
attacker to send packets with forged high Precedence value to congest some
internetrouter(s)andcauseall(ormost)trafcwithalowerPrecedencevalue
to be discarded.
4.2.2 Weak Type of Service
Section 5.2.4.3 of RFC 82 describes the algorithm for determining the
next-hopaddress(i.e.,theforwardingalgorithm).Bullet3,“WeakTOS”,
addresses the case in which routes contain a “type of service” attribute. It
statesthatincaseapacketcontainsanon-defaultTOS(i.e.,0000)only
routes with the same TOS or with the default TOS should be considered for
forwardingthatpacket.However,thismeansthatamongstthelongestmatch
routes for a packet are routes with a TOS other than the one contained in the
receivedpacketandnorouteswiththedefaultTOS,thusthecorresponding
packet would be dropped. This may or may not be a desired behavior.
Analternativetothiswouldbe,incasesamongstthe“longestmatch”routes
thereareonlyrouteswithnon-defaulttypeofserviceswhichdonotmatchthe
TOScontainedinthereceivedpacket,,tousearoutewithanyotherTOS.
While this route would most likely not be able to address the type of service
requestedbypacket,itwould,atleast,providea“besteffort”service.
It must be noted that Section 5.3.2 of RFC 82 allows for routers for not
honoring the TOSeld.Therefore,theproposedalternativebehaviorisstill
compliantwiththeIETFspecications.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 53/63
5
Security Assessment of the Internet Protocol
WhileofciallyspeciedintheRFCseries,TOS-basedroutingisnotwidely
deployed in the Internet.
4.2.3 Address Resolution
Inthecaseofbroadcastlink-layertechnologies,inorderforasystemto
transferanIPdatagramitmustusuallyrstmapanIPaddresstothe
correspondinglink-layeraddress(forexample,bymeansoftheARPprotocol
[Plummer,1982]).Thismeansthatwhilethisoperationisbeingperformedthe
packets that would require such a mapping would need to be kept in
memory. This may happen both in the case of hosts and in the case of
routers.
Thissituationmightbeexploitedbyanattackerwhichcouldsendalarge
amountofpacketstoanon-existenthostwhichwouldsupposedlybedirectlyconnected to the attacked router. While trying to map the corresponding IP
addressintoalink-layeraddress,theattackedrouterwouldkeepinmemory
allthepacketsthatwouldneedtomakeuseofthatlink-layeraddress.Atthe
pointinwhichthemappingfunctiontimesout,dependingonthepolicy
implementedbytheattackedrouter,onlythepacketthattriggeredthecallto
themappingfunctionmightbedropped.Inthatcase,thesameoperation
wouldberepeatedforeverypacketdestinedtothenon-existenthost.
Dependingonthetimeoutvalueforthemappingfunctionthissituationmight
lead to the router buffers to run out of free space with the consequence that
incominglegitimatepacketswouldhavetobedropped,orthatlegitimate
packetsalreadystoredintherouter’sbuffersmightgetdropped.Bothof
thesesituationswouldleadeithertoacompleteDenialofServiceortoa
degradation of the network service.
Onecounter-measuretothisproblemwouldbetodropatthepointthe
mapping function times out all the packets destined to the address that timed
out.Inaddition,a“negativecacheentry”mightbekeptinthemodule
performingthematchingfunction,sothatforsomeamountoftimethe
mapping function would return an error when the IP module requests to
perform a mapping for some address for which the mapping has recently
timed out.
A common implementation strategy for routers is that when a packet isreceived that requires an ARP request to be performed before the packet canbeforwarded,thepacketisdroppedandtherouteristhenengagedinthe
ARP procedure.
4.2.4 Dropping packets
In some scenarios it may be necessary for a host or router to drop packets
from the output queue. In the event one of such packets happens to be an IP
fragment,andtherewereotherfragmentsofthesamepacketinthequeue,
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 54/63
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 thosedescribedinRFC1918[Rekhteretal,1996],orthe“loopback”address),
there are a number of tricks an attacker can perform to reach them (e.g.
exploittheLSRRorSSRRIPoptions).Therefore,whenapplicable,packet
lteringshouldbeperformedatorganisationalnetworkboundarytoensure
that those addresses will be unreachable.
4.3.2 Private address space
The Internet Assigned Numbers Authority (IANA) has reserved the following
three blocks of the IP address space for private internets:
• 10.0.0.0-10.255.255.255(10/8prex)
• 172.16.0.0-172.31.255.255(172.16/12prex)
• 192.168.0.0-192.168.255.255(192.168/16prex)
UseoftheseaddressblocksisdescribedinRFC1918[Rekhteretal,1996].
Whereapplicable,packetlteringshouldbeperformedattheorganisational
perimeter to assure that these addresses are not reachable from outside the
enterprise network.
4.3.3 Class D addresses (224/4 address block)
TheClassDaddressescorrespondtothe224/4addressblockandareused
forInternetmulticast.ThereforeifapacketisreceivedwithaClassDaddress
as the Source Addressitshouldbedropped.Additionally,ifanIPpacket
with a multicast Destination Addressisreceivedforaconnection-oriented
protocol (e.g. TCP) the packet should be dropped.
4.3.4 Class E addresses (240/4 address block)
TheClassEaddressescorrespondtothe240/4addressblockandare
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 55/63
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)addressblockasusableunicastaddressspaces[Fulleretal,2008a][Fulleretal,2008b][Wilson
etal,2007].Therefore,werecommendimplementationstoacceptaddresses
inthe240/4blockasvalidaddressesfortheSource Address and
Destination Address.
It should be noted that the broadcast address 255.255.255.255 still must be
treated as indicated in Section 4.3.7 of this document.
4.3.5 Broadcast and multicast addresses, and connection-oriented
protocols
Forconnection-orientedprotocols,suchasTCP,sharedstateismaintained
betweenonlytwoendpointsatatime.Therefore,ifanIPpacketwitha
multicast (or broadcast) Destination Addressisreceivedforaconnection-
orientedprotocol(e.g.TCP),thepacketshouldbedropped.
4.3.6 Broadcast and network addresses
TheIETFspecicationsdidnotoriginallypermitIPaddressestohavethe
value0or-1foranyoftheHostnumber,networknumberorsubnetnumber
elds,exceptforthecasesindicatedinSection4.3.7.HoweverthischangedfundamentallywiththedeploymentofClasslessInter-DomainRouting(CIDR)
[FullerandLi,2006]becausewithCIDRasystemcannotknowwhatthe
subnet mask is for a particular IP address.
Manysystemsnowallowadministratorstousethevalues0or-1forthose
elds.DespitethataccordingtotheIETFspecicationstheseaddressesare
illegal,modernIPimplementationsshouldconsidertheseaddressestobe
valid.
4.3.7 Special Internet addresses
RFC1812[Baker,1995]discussestheuseofsomespecialinternet
addresses,whichisofinteresttoperformsomesanitychecksontheSource
Address and Destination AddresseldsofanIPpacket.Itusesthe
following notation for an IP address:
{<Network-prex>,<Host-number>}
RFC1122[Braden,1989]containedasimilardiscussionofspecialinternet
addresses,includingsomeoftheform{<Network-prex>,<Subnet-number>,
<Host-number>}.However,asexplainedinSection4.2.2.11ofRFC1812,in
aCIDRworld,thesubnetnumberisclearlyanextensionofthenetworkprexandcannotbeinterpretedwithouttheremainderoftheprex.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 56/63
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 anypurposeotherthanbootstrapping,thecorrespondingpacketshouldbe
silently dropped. If a packet is received with 0.0.0.0 as the Destination
Address it should be silently dropped.
{0, Host number}
Thisaddressmeans“thespeciedhost,inthisnetwork”.Asintheprevious
case,itismeanttobeusedonlyduringtheinitialisationprocedurebywhich
the host learns its own IP address. If a packet is received with such an
address as the Source Addressforanypurposeotherthanbootstrapping,it
should be dropped. If a packet is received with such an address as the
Destination Address it should be dropped.
{-1, -1}
This address is the local broadcast address. It should not be used as a
source IP address. If a packet is received with 255.255.255.255 as the
Source Address it should be dropped.
Somesystems,whenreceivinganICMPechorequest,forexample,willuse
the Destination Address in the ICMP echo request packet as the Source Addressoftheresponsetheysend(inthiscase,anICMPechoreply).Thus,
whensuchsystemsreceivearequestsenttoabroadcastaddress,the
Source Address of the response will contain a broadcast address. Thisshouldbeconsideredabug,ratherthanamalicioususeofthelimited
broadcast address.
{Network number, -1}
Thisisthedirectedbroadcasttothespeciednetwork.Asrecommendedby
RFC2644[Senie,1999],routersshouldnotforwardnetwork-directed
broadcasts.Thisavoidsthecorrespondingnetworkfrombeingutilisedas,for
example,a“smurfamplier”[CERT,1998a].
AsnotedinSection4.3.6ofthisdocument,manysystemsnowallow
administratorstoconguretheseaddressesasunicastaddressesfornetwork
interfaces. In such scenarios routers should forward these addresses as if
they were traditional unicast addresses.
In some scenarios a host may have knowledge about a particular IP address
beinganetwork-directedbroadcastaddressratherthanaunicastaddress(e.
g.thatIPaddressisconguredonthelocalsystemasa“broadcast
address”). If a system can infer the Source Address of a received packet is anetwork-directedbroadcastaddressthepacketshouldbedropped.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 57/63
55
Security Assessment of the Internet Protocol
AsnotedinSection4.3.6ofthisdocument,withthedeploymentofCIDR
[Fuler,2006],itmaybedifcultforasystemtoinferwhetheraparticularIP
address is a broadcast address.
{127, any}
This is the internal host loopback address. Any packet that arrives on any
physical interface containing this address as the Source Address,the
Destination Address,oraspartofasourceroute(eitherLSRRorSSRR)
should be dropped.
Forexample,packetswithaDestination Addressinthe127.0.0.0/8
address block that are received on an interface other than loopback should
be silently dropped. Packets received on any interface other than loopback
with a Source Address corresponding to the system receiving the packet
should also be dropped.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 58/63
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 CommunicationReview,Vol.19,No.2,pp.32-48.
Bellovin,S.M.2002. A Technique for Counting NATted Hosts.IMW’02,Nov.6-8,2002,Marseille,
France.
Bendi,1998.Boinkexploit.Availableat:
http://www.insecure.org/sploits/95.NT.fragmentation.bonk.html
Biondi,P.,Ebalard,A.2007.IPv6 Routing Header Security. CanSecWest 2007 Security Conference.
Available at: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.,andWeiss,W.,1998. An Architecture for
Differentiated Services. RFC 2475.
Braden,R.1989.Requirements for Internet Hosts -- Communication Layers. RFC 22.
Cerf,V.,andKahn,R.1974. A Protocol for Packet Network Intercommunication. IEEE Transactions on
Communications,Vol.22,No.5,May1974,pp.637-648.
CERT. 996a. CERT Advisory CA-1996-01: UDP Port Denial-of-Service Attack. Available at:
http://www.cert.org/advisories/CA-1996-01.html
CERT. 996b. CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoong Attacks. Available at:
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
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 59/63
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. WorkingGroup charter available at: http://www.ietf.org/proceedings/94jul/charters/cipso-charter.html
Cisco. 2003. Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 packet . Available at:
http://www.cisco.com/en/US/products/products_security_advisory09186a00801a34c2.shtml
Cisco. 2008. Cisco IOS Security Conguration Guide, Release 12.2. Available at:
http://www.cisco.com/en/US/docs/ios/12_2/security/conguration/guide/scpso.html
Clark,D.D.1982.IP datagram reassembly algorithms. RFC 85.
Clark,D.D.1988.The Design Philosophy of the DARPA Internet Protocols, Computer Communication
Review,Vol.18,No.4,pp.106-114.
daemon9,route,andinnity.1996. IP-spoong Demystied (Trust-Relationship Exploitation). Phrack
Magazine,VolumeSeven,IssueForty-Eight,File14of18.Availableat:http://www.phrack.org/
phrack/48/P48-14
Ed3f. 2002. Firewall spotting and networks analisys with a broken CRC.PhrackMagazine,Volume
0x0b,Issue0x3c,Phile#0x0cof0x10.Availableat:http://www.phrack.org/phrack/60/p60-0x0c.txt
Eddy,W.2007.TCP SYN Flooding Attacks and Common Mitigations. RFC 4987.
Ferguson,P.,andSenie,D.2000.Network Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoong. RFC 2827.
FIPS. 994. Standard Security Label for Information Transfer. Federal Information Processing
Standards Publication. FIP PUBS 188. Available at: http://csrc.nist.gov/publications/ps/ps188/
ps188.pdf
Fuller,V.,Li,T.2006.ClasslessInter-domainRouting(CIDR):The Internet Assignment and
Aggregation Plan. RFC 4632.
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 60/63
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/4 as usable unicast address space. IETFInternet-Draft(draft-fuller-240space-00.txt),workinprogress.
Fyodor,2004.Idle scanning and related IP ID games. Available at:
http://www.insecure.org/nmap/idlescan.html
GIAC. 2000. Egress Filtering v 0.2. Available at:
http://www.sans.org/y2k/egress.htm
Gill,V.,Heasley,J.,Meyer,D.,Savola,P.,Pignataro,C.2007.The Generalized TTL Security
Mechanism (GTSM). RFC 5082.
Gont,F.2006. Advanced ICMP packet ltering. Available at:
http://www.gont.com.ar/papers/icmp-ltering.html
Gont,F.2008.ICMP attacks against TCP ,IETFInternet-Draft(draft-ietf-tcpm-icmp-attacks-03.txt),
work in progress.
Graff,C.1995.IPv4 Option for Sender Directed Multi-Destination Delivery. RFC 770.
Haddad,I.,andZakrzewski,M.2004.Security Distribution for Linux Clusters.LinuxJournal.Available
at: http://www.linuxjournal.com/article/6943
Heffner,J.,Mathis,M.,andChandler,B.2006.IPv4Reassembly Errors at High Data Rates. RFC
4963.
Humble.1998.Nesteaexploit.Availableat:
http://www.insecure.org/sploits/linux.PalmOS.nestea.html
IANA. 2006a. Ether Types. Available at:
http://www.iana.org/assignments/ethernet-numbers
IANA. 2006b. IP Parameters. Available at:http://www.iana.org/assignments/ip-parameters
IANA. 2006c. Protocol Numbers. Available at:
http://www.iana.org/assignments/protocol-numbers
IRIX.2008.IRIX6.5trusted_networking(7)manualpage.Availableat:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/
catman/a_man/cat7/trusted_networking.z
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 61/63
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/les/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_
Predictable_IP_ID_Vulnerability.pdf
Kohno,T.,Broido,A.,andClaffy,K.C.2005.Remote Physical Device Fingerprinting. IEEE
TransactionsonDependableandSecureComputing.IEEETransactionsonDependableandSecure
Computing,Vol.2,No.2.
LBNL/NRG.2006.arpwatchtool.Availableat:
http://ee.lbl.gov/
Linux.2006.TheLinuxKernel.Availableat: http://www.kernel.org
Malkin,G.1993.Traceroute Using an IP Option. RFC 393
Mathis,M.,andHeffner,J.2007.Packetization Layer Path MTU Discovery. RFC 482.
Microsoft. 999. Microsoft Security Program: Microsoft Security Bulletin (MS99-038). Patch Available
for “Spoofed Route Pointer” Vulnerability. Available at:
http://www.microsoft.com/technet/security/bulletin/ms99-038.mspx
Miller,I.2001.Protection Against a Variant of the Tiny Fragment Attack. RFC 328.
Mogul,J.,Kent,C.,Partridge,C.,McCloghrie,K.1988. IP MTU Discovery Options. RFC 063.
Mogul,J.,andDeering,S.1990.Path MTU Discovery. RFC 9.
Nichols,K.,Blake,S.,Baker,F.,andBlack,D.1998.Denition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers. RFC 2474.
NISCC. 2004. NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP. Available at:
http://www.uniras.gov.uk/niscc/docs/re-20040420-00391.pdf
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 62/63
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, Trafc
Normalization, and End-to-End Protocol Semantics.USENIXConference,2001.
Plummer,D.C.1982. An Ethernet Address Resolution Protocol. RFC 826.
Postel,J.1981.Internet Protocol. DARPA Internet Program. Protocol Specication. RFC 79.
Ptacek,T.H.,andNewsham,T.N.1998. Insertion, Evasion and Denial of Service: Eluding Network
Intrusion Detection. Secure Networks, Inc. Available at:
http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps
Ramakrishnan,K.,Floyd,S.,andBlack,D.2001.The Addition of Explicit Congestion Notication
(ECN) to IP. RFC 368.
Rekhter,Y.,Moskowitz,B.,Karrenberg,D.,deGroot,G.J.,andLear,E.1996. Address Allocation for
Private Internets. RFC 98.
Sanlippo,S.1998a. about the ip header id.PosttoBugtraqmailing-list,MonDec141998.Available
at: http://www.kyuzz.org/antirez/papers/ipid.html
Sanlippo,S.1998b. Idle scan.PosttoBugtraqmailing-list.Availableat: http://www.kyuzz.org/antirez/papers/dumbscan.html
Sanlippo,S.1999. more ip id.PosttoBugtraqmailing-list.Availableat:
http://www.kyuzz.org/antirez/papers/moreipid.html
Savola,P.2006.MTU and Fragmentation Issues with In-the-Network Tunneling. 2006. RFC 4459.
SELinux.2008.SecurityEnhancedLinux.
Availableat:http://www.nsa.gov/selinux/
8/14/2019 Security Assessment of the Internet Protocol
http://slidepdf.com/reader/full/security-assessment-of-the-internet-protocol 63/63
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 Trafc.
Available at: http://www.icir.org/vern/papers/activemap-oak03.pdf
Shannon,C.,Moore,D.,andClaffy,K.C.2001.Characteristics of Fragmented IP Trafc on Internet
Links.
Shepler,S.,Callaghan,B,Robinson,D.,Thurlow,R.,Beame,C.,Eisler,M.,Noveck,D,2003.Network
File System (NFS) version 4 Protocol. RFC 3530.
Silbersack,M.J.2005.Improving TCP/IP security through randomization without sacricing
interoperability.EuroBSDCon2005Conference.Slidesavailableat:
http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf
Solaris. 2008. Solaris Trusted Extensions - Labeled Security for Absolute Protection. Available at:http://www.sun.com/software/solaris/ds/trusted_extensions.jsp#3
Song,D.1999.Frag router tool. Available at:
http://www.anzen.com/research/nidsbench/
St.Johns,M.1988.Draft Revised IP Security Option. RFC 038.
St.Johns,M.,Atkinson,R.,andThomas,G.2008.Common Architecture Label IPv6 Security Option
(CALIPSO).IETFInternet-Draft(draft-stjohns-sipso-03.txt),workinprogress.
Templin,F.2006.Requirements for IP-in-IP Tunnel MTU Assurance.IETFInternet-Draft(draft-templin-
mtuassurance-01.txt),workinprogress.
US-CERT.2001.US-CERT Vulnerability Note VU#446689: Check Point FireWall-1 allows fragmented
packets through rewall if Fast Mode is enabled. Available at:
http://www.kb.cert.org/vuls/id/446689
US-CERT.2002.US-CERT Vulnerability Note VU#310387: Cisco IOS discloses fragments of previous
packets when Express Forwarding is enabled. Available at:
http://www.kb.cert.org/vuls/id/310387
Watson,Paul.2004.Slipping in the Window: TCP Reset Attacks. CanSecWest 2004 Conference.
Wilson,P.,Michaelson,G.,Huston,G.2007.Redesignation of 240/4 from “Future Use” to “Limited
Use for Large Private Internets”.IETFInternet-Draft(draft-wilson-class-e-01.txt).
Zakrzewski M and Haddad I 2002 Linux Distributed Security Module Linux Journal Available at: