Results of a Security Assessment of the TCP and IP ... - Gont.com.ar

hollowtabernacleNetworking and Communications

Oct 26, 2013 (3 years and 10 months ago)

66 views

Resultsofa Security
AssessmentoftheTCP andIP
ProtocolsandCommon
ImplementationStrategies
Fernando Gont
projectcarriedout onbehalfofthe
UK CPNI
BSDCan2009 Conference
May 8-9, 2009, Ottawa, Canada
Agenda (I)

Project overview

Internet Protocolversion4

Identificationfield

TransmissionControl Protocol(TCP)

Overviewofbasicmechanisms

Securityimplicationsofa numberofheaderfields: TCP portnumbers,
TCP SequenceNumber, TCP Window

SecurityimplicationsoftheUrgentmechanism

SecurityimplicationsofsomeTCP options: MaximumSegmentSize
(MSS) option, andTimestampsoption

DiscussionofsomeTCP connection-floodingattacks

DiscussionofsomeattacksagainstTCP sendandreceivebuffers

DiscussionofsomeTCP/IP stackfingerprintingtechniques.

Conclusions
ProblemStatement(I) 
Duringthelasttwentyyears, manyvulnerabilitieswerefoundin a number
ofimplementationsoftheTCP & IP protocols, andin theprotocols
themselves, whichleadtothepublicationofa numberofvulnerability
reportsby vendorsandCSIRTs.

Documentationofthesevulnerabilitiesandthepossiblemitigationshas
beenspreadin a largenumberofdocuments.

Someonline documentationproposescounter-measureswithout
analyzingtheirinteroperabilityimplicationsontheprotocols. (i.e., wrong
and/ormisleadingadvice). Seee.g., Silbersack’spresentationat BSDCan
2006).

Whiletherehadbeena fair amountofworkonTCP security, theeffortsof
thesecuritycommunityhadneverreflectedin changesin the
correspondingIETF specifications, andsometimesnoteven in the
protocolimplementations.
Problemstatement(II) 
Itisverydifficulttoproduce a secure/resilientimplementationofthe
TCP/IP protocolsfromtheIETF specifications.

Therewasno single documentthatprovideda thoroughsecurity
assessmentoftheTCP andIP protocols, andthattriedtounifycriteria
aboutthesecurityimplicationsoftheprotocols, andthebest possible
mitigationtechniques.

Therewasno single documentthatservedas a complementtotheofficial
IETF specifications, in thehopeofmakingthetaskofproducinga secure
implementationoftheprotocolseasier.

Newimplementationsoftheprotocolsre-implementbugs/vulnerabilities
foundin olderimplementations.

Newprotocolsre-implementmechanismsorpolicieswhosesecurity
implicationshavebeenknownfromotherprotocols(e.g., Router Header
Type0 in IPv6vs. IPv4sourcerouting).
Project overview

Duringthelastfewyears, CPNI –formerlyNISCC –embarkeditselfin a
projecttofillthisgap.

Thegoalwastoproduce a set ofdocumentsthatwouldserveas a
securityroadmapfortheTCP andIP protocols, withthegoalofraising
awarenessaboutthesecurtyimplicationsoftheprotocols, so thatexisting
implementationscouldbe patched, andnewimplementationswould
mitigatethemin thefirstplace.

Thisset ofdocumentswouldbe updatedin response tothefeedback
receivedfromthecomunity.

Finally, weplannedtotaketheresultsofthisprojecttotheIETF, so that
therelevantspecificationscouldbe modifiedwhereneeded.
Ouputofthisproject 
SecurityAssesmentoftheInternet Protocol

In July 2008 CPNI publishedthedocument“SecurityAssessmentofthe
Internet Protocol”--consistingof63 pages, whichincludetheresultsofour
securityassessmentofIPv4.

Shortlyafter, wepublishedthesamedocumentas anIETF Internet-Draft
(draft-gont-opsec-ip-security-00.txt)

TheInternet I-D wasfinallyadopted(by theendof2008) by theIETF.

SecurityAssessmentoftheTransmissionControl Protocol(TCP)

In February2009 CPNI publishedthedocument“SecurityAssessmentofthe
TransmissionControl Protocol(TCP)”--consistingof130 pages, whichinclude
theresultsofoursecurityassessmentofIPv4.

Shortlyafter, wepublishedthesamedocumentas anIETF Internet-Draft
(draft-gont-tcp-security-00.txt)

Thereiscurrentlya veryheateddebate aboutthisdocumentat theIETF
betweenthosethatsupporttheidea thattheTCP specificationsshouldbe
maintained/updated, andthosewhoaguethattheyshouldbe left“as is”.
Internet Protocolversion4
SecurityImplicationsof
theIdentificationfield
IP IDentificationfield 
TheIP Identification(IP ID) fieldisusedby theIP framentation
mechanism.

Thetuple{SourceAddress, DestinationAddress, Protocol, Identification}
identifiesfragmentsthatcorrespondtothesameoriginal datagram, and
thusthetuplecannotbe simultaneouslyusedformore thanonepacketat
anygiventime.

Ifa tuple{SourceAddress, DestinationAddress, Protocol, Identification}
thatwasalreadyin use foranIP datagramwerereusedforsomeother
datagram, thefragmentsofthesepacketscouldbe incorrectly
reassembledat thedestinationsystem.

These“IP ID collisions”havetraditionallybeenavoidedby usinga counter
fortheIdentificationfield, thatwasincrementedby oneforeachdatagram
sent.

Thus, a specificIP ID valuewouldonlybe reusedwhenalltheother
valueshavealreadybeenused.
SecurityimplicationsoftheIdentificationfield 
Ifa global counterisusedforgeneratingtheIP ID values, theIP
Identificationfieldcouldbe exploitedby anattackerto:

Inferthepackettransmissionrateofa remote system

Countthenumberofsystemsbehinda NAT

Performa stealthportscanning
RandomizingtheIdentificationfield 
In ordertomitigatethesecurityimplicationsoftheIdentificationfield, the
IP ID shouldnotbe predictable, andshouldnotbe set as a resultofa
global counter.

However, ithas alwaysbeenassumedthattrivial randomizationwouldbe
inappropriate, as itwouldleadtoIP ID collisionsandhenceto
interoperabilityproblems.

Somesystems(e.g., OpenBSD) haveempoyedPRNG schemestoavoid
quickreuseoftheIP ID values. However, theyhavebeenfoundto
produce predictablesequences.

Ananalysisoftheuse offragmentationforconnection-oriented(CO) and
forconnection-less(CL) protocolscan shedsomelightaboutwhichPRNG
couldbe appropriate.
RandomizingtheIP ID: CO protocols 
Connection-orientedprotocols:

Theperformance implicationsofIP fragmentationhavebeenknownfor
about20 years.

Mostconnection-orientedprotocolsimplementmechanismsfor
avoidingfragmentation(e.g., Path-MTU Discovery)

Additionally, giventhecurrentbandwidthavailability, andconsidering
thattheIP ID is16-bitlong, itisunacceptabletorelyonIP
fragmentation, as IP ID valueswouldbe reusedtooquiklyregardless
ofthespecificIP ID generationscheme.

Wethereforerecommendthatconnection-orientedprotocolsnotrelyonIP
fragmentation, andtheyrandomizethevaluetheyuse fortheIP
Identificationfieldofoutgoingsegments.
RandomizingtheIP ID: CL protocols 
Connection-lessprotocols

Theytypicallylackof:

flowcontrol mechanisms

packetsequencingmechanisms

reliabilitymechanisms

Thescenariosandapplicationsforwhichtheyare usedassumethat:

Applicationswillbe usedin environmentsin whichpacket-
reorderingisunlikely.

Thedata transfer rateswillbe lowenoughthatflowcontrol is
unnecessary

Packetlossisnotimportantandprobablyalsounlikely.

Wethereforerecommendconnection-lessprotocolstosimplyrandomize
theIP ID.

Applicationsconcernedwiththispolicyshouldconsiderusinga
connection-orientedtransportprotocol.
TransmissionControl
Protocol(TCP)
OverviewoftheTCP
connection-establishment
andconnection-termination
mechanisms
Connection-establishment

Theconnectionestablishmentphaseusuallyinvolvestheexchangeof
threesegments(henceit’scalled“three-wayhandshake).

Once thethree-wayhandshakehas completed, thesequencenumbers
(andotherparameters) willbe properlysynchronized, andthedata
transfer can proceed.
Connectiontermination 
Theconnectionterminationphaseusuallyinvolvestheexchangeoffour
segments

TheTCP thatbeginstheconnection-terminationphase(Host A) usually
staysin theTIME-WAIT statefor4 minutes, whiletheotherend-point
movestothefictionalCLOSED state(i.e., itdoesnotkeepanystatefor
thisconnection
Collisionofconnection-id’s 
DuetotheTIME-WAIT state, itispossiblethatwhena connection-requestissent
toa remote peer, therestillexistsa previousincarnationofthatconnectionin the
TIME-WAIT state. In thatscenario, theconnection-requestwillfail.

Itisclearthatthecollissionofconnection-id’sisundesirable, andthus
shouldbe avoided.
RFC 793 RFC 1337
SecurityImplicationsofa
numberofTCP header
fields
TCP SourcePort &
DestinationPort
TCP portnumbers 
Trust relationships

Whilesomesystemsrequiresuperuserprivilagestobindportnumbersin the
range1-1023, no trustshouldbe grantedbasedonTCP portnumbers.

Specialportnumbers

TheSocketsAPI uses port0 toindicate“anyport”. Therefore, a portnumberof
0 isneverusedin TCP segments.

Port 0 shouldnotbe allowedneitheras a sourceportnoras a destinationport.

Ephemeralportrange

TheIANA has traditionallyreservedtherange49152-65535 fortheDynamic
and/orPrivateports(i.e., theephemeralports)

However, differentTCP implementationsuse differentportrangesforthe
ephemeralports(e.g., 1024-4999, 32768-65535, 49152-65535, etc.)

WerecommendTCP implementationstouse therange1024-65535 forthe
ephemeralports.
Ephemeralportselectionalgorithms 
Whenselectinganephemeralport, theresultingconnection-id(client
address, clientport, serveraddress, serverport) mustnotbe currentlyin
use.

Ifthereiscurrentlya local TCB withthatconnection-id, anotherephemeral
portshouldbe selected, suchthatthecollisionofconnection-id’sissolved.

However, itisimpossibleforthelocal systemtoactuallydetectthatthere
isanexistingcommunicationinstancein a remote systemusingthat
connection-id(suchas a TCP connectionin theTIME-WAIT state).

In theeventtheselectionofanephemeralportresultedin connection-id
thatwascurrentlyin use at theremote system, a “collisionofconnectio-
id’s”wouldoccur.

As a result, the frequency of reuse of connection-id’s should be low
enough such that collisions of connection-id’s are minimized.
TCP Port Randomization

ObfuscationoftheTCP ephemeralports(andhencetheconnection-id)
helpstomitigateblindattacksagainstTCP connections

Thegoalistoreduce thechancesofanoff-pathattackerfrompredicting
thepehemeralportsusedforfutureconnections.

Simple randomizationhas beenfoundtoleadtointeroperabilityproblems
(connectionfailures). (SeeSilbersack’spresentationat BSDCan2006).

A goodportrandomizationalgorithmshould:

Minimizethepredictabilityoftheephemeralportnumbersby anoff-
pathattacker.

Avoidquickre-use oftheconnection-id’s

Avoidtheuse ofportnumbersthatare neededforspecificapplications
(e.g., port80).
A goodportrandomizationalgorithm 
TheIETF Internet-Draft“Port Randomization”[Larsen, M. andGont, F.,
2008] describes anephemeralportselectionalgorithmthat’sbasedon
anexpressionintroducedby Steven BellovinfortheselectionofISN’s:
Port = counter+ F(local_IP, remote_IP, remote_port, secret_key)

Itseparatestheportnumberspaceforconnectingtodifferentend-points

Ithas beenfound(empyrically) tohavebetterinteroperabilityproperties
thanotherobfuscationschemes

ItshipswiththeLinux kernel already.
Sampleoutput ofthealgorithm 
Sampleoutput oftherecommendedalgorithm.
305210286553510241000128.0.0.1:80#5
655110276553510244500170.210.0.1:80#4
655010266553510244500170.210.0.1:80#3
304910256553510241000128.0.0.1:80#2
304810246553510241000128.0.0.1:80#1
port
next_ephemeral
max_ephemeral
min_ephlemeral
offset
IP:port
Nr.
TCP SequenceNumber
InitialSequenceNumbers(I) 
RFC 793 suggeststhatISN’smustresultin a monotonicallyincreasing
sequence(e.g., froma global timer), so thatthesequencenumberspace
ofdifferentconnectionsdoesnotoverlap. Fromthatpointon, ithas been
assumedthatthegenerationofISN’ssuchthattheyare monotonically
increasingiskeytoavidthatcorruptionin TCP (thatcouldresultfrom“old”
segmentsreceivedfora newconnection).

However, protectionagainstoldsegmentsisreallyprovidedin TCP by two
othermechanismsthathavenothingtodo withtheISN’s:

“Quiettime concept”: Afterbootstrapping, a systemmustrefrainfrom
sendingTCP segmentsfor2*MSL.

TIME-WAIT state: Whena TCP connectionisterminated, theend-point
thatperformedthe“active close”mustkeeptheconnectionin the
TIME-WAIT statefor2*MSL, thusensuringthatallsegmentsdisapear
fromthenetworkbeforea newincarnationoftheconnectioniscreated.
Initialsequencenumbers(II) 
In thetraditionalBSD implementation, theISN generatorwasinitilizedto1
duringsystemboot-strap, andwasincrementedby 64000 everyhalf
second, andby 64000 foreachestablishedconnection.

BasedontheassumptionthatISN’sare monotonicallyincreasing, BSD
implementationsintroducedsomeheuristicsforallowingquickreuseofthe
connection-ID’s. Ifa SYN isreceivedfora connectionthatisin theTIME-
WAIT state, then,

IftheISN oftheSYN islargerthanthelastsequencenumberseenforthat
directionofthedata transfer (SEG.SEQ> RCV.NXT), theTCB in theTIME-
WAIT stateisremoved, andanotherTCP iscreatedin theSYN-RECEIVED
state.

Otherwise, theprocessingrules in RFC 793 are followed.

Itisveryinterestingtonote thatthishackwasmotivatedby theuse ofthe
r* commands. Thatis, forshort-livedconnections, thattypicallytransfer
smallamountsofdata, and/orthattypicallyuse a lowtransfer rate..
Otherwise, theseheuristicsfail.
ISN randomization

TheimplicationsofpredictableISN generatorshavebeenknownfora
long time.

ISN obfuscationhelpstomitigateblind-attacksagainstTCP connections.

ThegoalofISN obfuscationistopreventoff-pathattackersfromguessing
theISNsthatwillbe usedforfutureconnections.

A numberofTCP implementations(e.g., OpenBSD) simplyrandomizethe
ISN, thuspotentiallycausingtheBSD hacktofail. In thatscenario,
connectionfailuresmay be experienced.

WerecommendgenerationoftheISNsas proposedby S. Bellovinin RFC
1948:
ISN = M + F(localhost, localport, remotehost, remoteport, secret)

Thisschemeproduces separatesthesequencenumberspaceforeach
connection-id, andgeneratesISNsthatare monotonically-increasing
withintheirrespectivesequencenumberspaces.
TCP Window
TCP Window

TheTCP Windowimposesanupperlimitonthemaximumdata transfer
ratea TCP connectioncan achieve
MaximumTransfer Rate= Window/ Round-TripTime

Therefore, underideal networkconditions(e.g., no packetloss), theTCP
Windowshouldbe, at least:
TCP Window>= 2 * Bandwidth* Delay

A numberofsystemsandapplicationsusetarbitrarilylargeTCP Windows,
in thehopeofavoidingtheTCP Windowfromlimitingthedata transfer
rate.

However, largerwindowsincreasethesequencenumberspacethatwill
be consideredvalidforincomingconnections, thereforeincreasingthe
chancesofanoff-pathattackerofsuccessfullyperforminga blind-attack
againsta TCP connection.

Advice: Ifanapplicationdoesn’trequirehigh-throughput(e.g., H.245), use
a smallwindow(e.g., 4 KBytes).
TCP Urgentmechanism(URG flagandUrgentPointer)
Urgentmechanism 
Theurgentmechanismprovidea meansforanapplicationtoindicatean
“interestingpoint”in thedata stream(usuallya pointin thestreamthe
receivershouldjumpto). Itisnotmeanttoprovidea mechanismfor
out-of-band(OOB) data.

However, moststacksimplementtheurgentmechanismas out ofband
data, puttingtheurgentdata in a differentqueuethannormal data.
Ambiguitiesin thesemanticsoftheUP 
There’sa mismatchbetweentheIETF specificationsandvirtuallyallreal
implementations.

“theurgentpointerpointstothelastbyte ofurgentdata”(IETF) vs. “the
UrgentPointerpointstothebyte followingthelastbyte ofurgentdata”
(virtuallyallimplementations)

Mostimplementationsneverthelessincludea (broken) system-widetoggle
toswitch betweenthesetwopossiblesemanticsoftheUrgentPointer
IETF specsVirtuallyallimplementations
Urgentdata as OOB data 
TCP/IP stacksdifferin how theyimplementUrgentData as OOB.

Virtuallyallstacksonlyaccepta single byte ofOOB data

Otherstacks(Microsoft’s) acceptOOB data ofanylength(*).
(*) Ithas beenreportedthattheydo notenforcelimitsontheamountofOOB queued!
VirtuallyallstacksMicrosoft’sstack
Urgentdata in thecurrentInternet 
Somemiddle-boxes(e.g., Cisco Pix), by default, cleartheURG flagand
set theUrgentPointertozero, thuscausingthe“urgentdata”tobecome
“normal data”.

Itisclearthaturgentindicationsare notreliablein thecurrentInternet.
Adviceontheurgentmechanism 
Alltheaforementionedissuesleadtoambiguitiesin how urgentdata may
be interpretedby thereceivingTCP, thusrequiringmuchmore workon
e.g., NIDS.

As discussedbefore, theurgentmechanismisunreliablein thecurrent
Internet (i.e., somewidelydeployedmiddle-boxesbreakitby default).

Advice: Applicationsshouldnotrelyontheurgentmechanism.

Ifused,

Itshouldbe usedjustas a performance improvement

Applicationsshouldset theSO_OOBINLINEsocketoption, so that
“urgentdata”are procesedinline.
TCP Options
MSS (MaximumSegmentSize) option 
Usedtoindicatetotheremote TCP themaximumsegmentsizethisTCP
iswillingtoreceive.

Somevaluesare likelytocause undesirablebehavior

A valueof0 mightcause a connectionto“freeze”, as itwouldnotallow
anydata tobe includedin theTCP payload.

Othersmallvaluesmay havea performance impactontheinvolved
systems. e.g., theywillresultin a higheroverheadandhigherinterrupt
rate

ThesecurityimplicationsoftheMSS werefirstdiscussedin 2001, butthe
communityneverpruducedanymitigations.

Advice: SanitizetheMSS optionas follows:
Sanitized_MSS= max(MSS, 536)
Eff.snd.MSS= min(Sanitized_MSS+20, MMS_S) -TCPhdrsize-IPoptionsize
Timestampsoption 
TCP timestampsare usedtoperformRound-TripTime (RTT)
measurementandProtectionAgainstWrappedSequenceNumbers
(PAWS)

ForthepurposeofPAWS, timestampsare requiredtobe monotonically
increasing. However, there’sno requirementthatthetimestampsbe
monotonicallyincreasingaccrossTCP connections.

Generationoftimestampssuchthattheyare monotonicallyincreasing
allowsanimprovedhandlingofconnection-requests(SYN segments)
whenthere’sa TCB in theTIME-WAIT state.

ManystacksselecttheTCP timestampsfroma global timer, whichis
initializedtozerouponsystembootstrap.
SecurityimplicationsofTCP timestamps 
PredictableTCP timestampshavea numberofsecurityimplications:

In ordertoperforma blindattackagainsta TCP connectionthat
employsTCP timestamps, anattackermustbe abletoguessorknow
thetimestampvaluesin use.

By forginga TCP segmentwitha timestampthatislargerthanthelast
timestampreceivedforthetargetconnection, anattackercouldcause
theconenctiontofreeze.

Therefore, system-wideTCP timestampsare discouraged.

Furthermore, ifthetimestampsclockisinitilizedtoa fixedvalueat system
bootstrap, thetimestampswillleakthesystemuptime.
AdviceonTCP timestamps 
Advice: Generatetimestampswitha RFC1948-likescheme:
timestamp = T() + F(localhost, localport, remotehost, remoteport, secret_key)

Thisexpressionprovidesa per-destination-endpointmonotonically-
increasingsequence, thusaenablingtheimprovedhandlingofSYN
segmentswhileavoidinganoff-pathattackerfromguessingthetimestamp
valuesusedfornewconnections.

Thistimestampsgenerationschemehas beenincorporatedin Linux

Itwillmostlikelybe adoptedby theIETF in therevisionoftheTCP
timestampsoptionRFC.
Connection-flooding
attacks
Somevariantsofconnection-floodingattacks 
SYN-flood: aimsat exhaustingthenumberofpendingconnectionsfora
specificTCP port

Naphta: aimsat exhaustingthenumberofongoingconnections

FIN-WAIT-2 flood: aimsat exhaustingthenumberofongoingconnections,
withconnectionsthatare notcontrolledby a user-spaceprocess.

Netkill: aimsat exhaustingsystemmemoryusedfortheTCP
retransmissionby issuinga largenumberofconnectionrequestsfollowed
by applicationrequests, andabandoningthoseconnections.
Naphta

Thecreationandmaintenanceofa TCP connectionrequiressystem
memorytomaintainsharedstatebetweenthelocal andtheremote TCPs.

Giventhatsystemmemoryisa limitedresource, thiscan be exploitedto
performa DoSattack(thisattackvector has beenreferredtoas “Naphta”).

In ordertoavoidwastinghisownresources, anattackercan bypass the
kernel implementationofTCP, andsimplycrafttherequiredpacketsto
establisha TCP connectionwiththeremote endpoint, withouttyinghis
ownresources.

Counter-measures

Enforcingper-userandper-processlimits

Limitingthenumberofsimultaneousconnectionsat theapplication

Limitingthenumberofsimultaneousconnectionsat firewalls.

Enforcinglimitsonthenumberofconnectionswithno user-space
controllingprocess.

A typicalconnection-terminationscenario:

Problemsthatmay potentiallyariseduetotheFIN-WAIT-2 state

There’sno limitontheamountoftime a connectioncan stayin the
FIN-WAIT-2 state

At thepointa TCP getsintotheFIN-WAIT-2 statethere’sno user-
spacecontrollingprocess
FIN-WAIT-2 floodingattack
CountermeasuresforFIN-WAIT-2 flooding 
Enforcea limitonthedurationoftheTIME-WAIT state. E.g., Linux 2.4
enforcesa limitof60 seconds. Once thatlimitisreached, theconnection
isaborted.

Thecounter-measuresfortheNapthaattackstillapply. However, thefact
thatthisattackaimsat leavinglotsofconnectionsin theFIN-WAIT-2 state
willusuallypreventanapplicationfromenforcinglimitsonthenumberof
ongoingconnections.

Applicationsshouldbe modifiedso thattheyretaincontrol ofthe
connectionformoststates. Thiscan be achievedby replacingthe
employinga conbinationoftheshutdown(), setsockopt(), andclose().

TCP shouldalsoenforcelimitsonthenumberofongoingconnectionswith
no user-spacecontrollingprocess.
Securityimplicationsof
theTCP sendandreceive
buffers
TCP retransmission(send) buffer 
TheNetkillattackaimsat exhaustingthesystemmemoryusedforthe
TCP retransmissionbuffer.

Theattackerestablishesa a largenumberofTCP connectionswiththe
targetsystem, isuesanapplicationrequest, andabandonsthe
aforementionedconnections.

Thetargetsystemwillnotonlywastethesystemmemoryusedtostore the
TCB, butalsothememoryusedtoqueuethedata tobe sent(in response
totheapplicationrequest).
Counter-measuresfortheNetkillattack 
ThecountermeasuresfortheNaphtaattackstillapply.

In addition, as themaliciousconnectionsmay endup in theFIN-WAIT-1
state, applicationsshouldbe modifiedso thattheyretaincontrol ofthe
connectionformoststates. Thiscan be achievedby replacingthe
employinga conbinationoftheshutdown(), setsockopt(), andclose().

Whenresourceexhaustionisimminent, a connection-prunningpolicy
mighthavetobe applied, payingattentionto

Connectionsthathaveadvertiseda 0-windowfora long time

Connectionsforwhichthefirstfewwindowsofdata havebeen
retransmitteda largenumberoftimes

Connectionsthatfallin oneofthepreviouscategories, andforwhich
onlya smallamountofdata havebeensuccessfullytransferredsince
theirestablishment.
TCP reassembly(receive) buffer 
When out-of-order data are received, a “hole”momentarily exists in the
data stream which must be filled before the received data can bedelivered
to the application making use of TCP’s services.

This mechanism can be exploited in at least two ways:

An attacker could establish a large number of TCP connections and
intentionally send a large amount of data on each of those connections
to the receiving TCP, leaving a hole in the data stream so that those
data cannot be delivered to the application.

Same as above, but the attacker would send e.g., chunks of one byte
of data, separated by holes of e.g., one byte, targeting the overhead
needed to hold and link each of these chunks of data.
Improvementsforhandlingout-of-orderdata 
TCP implementationsshouldenforcelimitsontheamountofout-of-order
data thatisqueuedat anytime.

TCP implementationsshouldenforcelimitsonthemaximumnumberof
“holes”thatare allowedforeachconnection.

Ifnecessary, out-of-orderdata couldbe discarded, withno effecton
interoperability. Thishas a performance penalty, though.
Remote OperatingSystem
detectionviaTCP/IP stack
fingerprinting
Overview

A numberoftools, suchas nmap, can performdetecttheoperatingsystem
in use at a remote system, viaTCP/IP stackfingerprinting

Thisisachivedby analyzingtheresponse oftheTCP/IP stacktoa number
ofprobesthatdifferentstackprocessin differentways

Theprecisionoftheirresultsisamazinglygood. –Itshouldn’tbe that
good!

Question: Wouldn’titbe possiblefortheseTCP/IP stackstorespondto
mostoftheseprobesin exactlythesameway?
FIN probe

TheIETF specificationsleaveitunspecifiedhow TCP shouldrespond
whena packetthatdoesnothavetheSYN orACK bits set isreceivedfor
a connectionthatisin theLISTEN state.

SomestacksrespondwithanRST, whileotherssilentlydropthesegment.

Advice: rejectwithanRST thoseTCP segmentsthatdo nothavetheSYN
orACK bits set andthatare receivedfora connectionin theLISTEN state.
In allothercases, followtherules in RFC 793.
Bogusflagtest 
Theattackersendsa TCP segmentwithat leastoneoftheReservedbits
set.

Somestacksignore thisfield, whileothersreset theconnection, orreflect
thefieldin theTCP segmentsentin response.

Advice: Ignore any flags not supported, and not reflect them if a TCP
segment is sent in response to the one just received.
RST sampling

Differentimplementationsdifferin theAcknowledgementNumbertheyuse
in response tosegmentsreceivedforconnectionsin theCLOSED state.

IftheACK bitin theincomentsegmentisoff, theresponse shouldbe:
<SEQ=0><ACK=SEG.SEQ+SEG.LEN+flags><CTL=RST, ACK>

IftheACK bitin theincomingsegmentison, theresponse shouldbe:
<SEQ=SEG.ACK><ACK=SEG.SEQ+SEG.LEN+flags><CTL=RST, ACK>

Thatis, theAcknowledgmentnumbershouldbe set totheSEQ ofthe
incomingsegment, plus thesegmentlength, andBE incrementedby one
foreachflagthatset in theorginalsegmentthatoccupiesonbyte in the
sequencenumberspace.
Port-0 probe

TheSocketsAPI uses port0 toindicate“anyport”. Therefore, a port
numberof0 isneverusedin TCP segments.

Differentimplementationsdifferin how theyprocessTCP segmentsthat
use 0 as theSourceand/orDestinationport(e.g., somewillallowtheir
use, somewillrejectincomingconnectionrequests, andsomewillsilently
droptheincomingconnectionrequests). Thishas beenexploitedfor
remote OS detectionviaTCP/IP stackfingerprinting.

Advice: rejectwithanRST TCP segmentsthatuse portnumber0 (thatdo
nothavetheRST bitset).
TCP optionordering 
DifferentTCP implementationsenabledifferentoptions(by default) in their
TCP connections.

Additionally, theyframetheoptionsdifferently.

Theremay be reasonsfora TCP toincludeornotincludesomespecific
options. Ontheotherhand, how toframetheoptionsis, forthemostpart,
simplya matterofchoice.

More workisneededtogetconsensusonwhichoptionsshouldbe
includedby default, andhow toframethem.

Anadditionalbenefitresultingfromarrivingtosuchconsensusisthat
stackscouldimplement“TCP optionprediction”(i.e., tune thecodeso that
processingofpacketswiththeusual optionsin theusual orderisfaster).
Additionalfingerprintingtechniques 
Otherparameterscan be sampledwiththeintenttocorrelatethemwith
specificimplementationsofTCP:

ISN: Whilewerecommendimplementationoftheschemedescribedin
RFC1948, somestackscouldsifferentin thegranularityofthetimer
thattheyuse.

Initialwindow: Differentstacksuse differentvaluesfortheTCP
Windowadvertisedin SYN segments. More workisneededtopossibly
arrivetoconsensusonthedefaultvaluetobe used.

RetransmissionTimeOut(RTO): Differentstacksuse different
valuesforthisparameter. However, ofallthefingerprintingtechniques,
thisistheonethatislessofa concern, as itsprecisionishighly-
dependentonthenetworkconditions.
Conclusions& Further
Work
ConclusionsandFurtherWork 
WorkingonTCP/IPv4securityin 2005/2008 probablydidn’thavemuch
glamour. However, thiswassomethingthatneededtobe done.

Unfortunately, manypeoplewillnotreadpasttheprefaceofthe
documents, butwillneverthelessclaimthat“there’snothingnewin this
documents”.

Thereseemstobe resistancein theIETF toupdate/fixthespecs. –Get
involved!

We’reawareofsomeeffortsin thevendorcommunitytoimprovethe
security/resiliencyofTCP. Notsurewhattheendresultwillbe.

Yourfeedback reallymatters.
Questions?
Acknowledgements

UK CPNI, fortheircontinuedsupport
Fernando Gont
fernando@gont.com.ar
http://www.gont.com.ar