TCP provides reliable data transmission through mechanisms like the three-way handshake, congestion control using AIMD, and fast retransmit. However, it is vulnerable to attacks like RST injection to terminate connections or FIN scans to detect open ports. Defenses include randomizing sequence numbers, stateful firewalls to validate packets, and intrusion detection systems to detect scanning behaviors.

1. TCP Congestion
avoidance/RST attacks
Ahmed Kamel Taha

2. Introduction
 TCP and UDP works in Transport Layer of OSI Model as well as
TCP/IP Model
 TCP (Transmission Control Protocol) enables two hosts to establish
a connection and exchange streams of data. TCP guarantees
delivery of data and also guarantees that packets will be delivered
in the same order in which they were sent.
 UDP (User Datagram Protocol) a connectionless protocol that, like
TCP, runs on top of IP networks. Provides very few error recovery
services, offering instead a direct way to send and receive
datagrams over an IP network.

3. Advantages of TCP
 TCP guarantees three things: that your data gets there, that it gets there in order, and
that it gets there without duplication. (the truth, the whole truth, and nothing but the
truth...)
 TCP does Flow Control and Congestion Control
 For a programmer: The operating system does all the work. you just sit back and watch
the show. no need to have the same bugs in your code that everyone else did on their
first try; it's all been figured out for you.
 Since it's in the OS, handling incoming packets has fewer context switches from kernel
to user space and back; all the reassembly, acking, flow control, etc is done by the
kernel.
 Routers may notice TCP packets and treat them specially. they can buffer and retransmit
them
 TCP has good relative throughput on a modem or a LAN.

4. Disadvantages of TCP
 TCP cannot conclude a transmission without all data in motion
being explicitly acked.
 TCP cannot be used for broadcast or multicast transmission.
 TCP has no block boundaries; you must create your own.
 For a programmer:
 OS might be buggy –as well TCP
 TCP may have lots of features you don't need. it may waste bandwidth, time, or
effort on ensuring things that are irrelevant to the task at hand.
 Routers on the internet today are out of memory. they can't pay
much attention to TCP flying by, and try to help it. design
assumptions of TCP break down in this environment.
 Provides much latency in network- SLOW

5. Where are they used? Why?
 TCP is used in HTTP, HTTPs, FTP, SMTP Telnet etc...
 UDP is used in DNS, DHCP, TFTP, SNMP, RIP, VOIP, Multi media, Online
games etc…
 Consider Multi media, if we use TCP instead of UDP when ever pocket
loss occurred we get long delay to continue watching/listening because
TCP is retransmitting lost packets and it takes time

7. 7
TCP Congestion Control
Essential strategy :: The TCP host sends packets
into the network without a reservation and then
the host reacts to observable events.
Originally TCP assumed FIFO queuing.
Basic idea :: each source determines how much
capacity is available to a given flow in the
network.
ACKs are used to ‘pace’ the transmission of
packets such that TCP is “self-clocking”.

8. 8
AIMD
(Additive Increase / Multiplicative Decrease)
CongestionWindow (cwnd) is a variable held by
the TCP source for each connection.
cwnd is set based on the perceived level of
congestion. The Host receives implicit (packet
drop) or explicit (packet mark) indications of
internal congestion.
MaxWindow :: min (CongestionWindow , AdvertisedWindow)
EffectiveWindow = MaxWindow – (LastByteSent -LastByteAcked)

9. 9
Additive Increase
Additive Increase is a reaction to perceived
available capacity.
Linear Increase basic idea:: For each “cwnd’s
worth” of packets sent, increase cwnd by 1
packet.
In practice, cwnd is incremented fractionally for
each arriving ACK.
increment = MSS x (MSS /cwnd)
cwnd = cwnd + increment

10. 10
Figure 6.8 Additive Increase
Source Destination
Add one packet
each RTT

11. 11
Multiplicative Decrease
* The key assumption is that a dropped packet and the
resultant timeout are due to congestion at a router or a
switch.
Multiplicate Decrease:: TCP reacts to a timeout by halving
cwnd.
Although cwnd is defined in bytes, the literature often
discusses congestion control in terms of packets (or more
formally in MSS == Maximum Segment Size).
cwnd is not allowed below the size of a single packet.

12. 12
AIMD
(Additive Increase / Multiplicative Decrease)
It has been shown that AIMD is a necessary condition
for TCP congestion control to be stable.
Because the simple CC mechanism involves timeouts
that cause retransmissions, it is important that hosts
have an accurate timeout mechanism.
Timeouts set as a function of average RTT and
standard deviation of RTT.
However, TCP hosts only sample round-trip time once
per RTT using coarse-grained clock.

13. 13
Figure 6.9 Typical TCP
Sawtooth Pattern
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
Time (seconds)
70
30
40
50
10
10.0

15. 15
Slow Start
Linear additive increase takes too long to
ramp up a new TCP connection from cold
start.
Beginning with TCP Tahoe, the slow start
mechanism was added to provide an initial
exponential increase in the size of cwnd.
Remember mechanism by: slow start prevents
a slow start. Moreover, slow start is slower
than sending a full advertised window’s
worth of packets all at once.

16. 16
Slow Start
The source starts with cwnd = 1.
Every time an ACK arrives, cwnd is incremented.
cwnd is effectively doubled per RTT “epoch”.
Two slow start situations:
 At the very beginning of a connection {cold start}.
 When the connection goes dead waiting for a timeout
to occur (i.e, the advertized window goes to zero!)

17. 17
Figure 6.10 Slow Start
Source Destination
Slow Start
Add one packet
per ACK

18. 18
Slow Start
 However, in the second case the source has more information. The
current value of cwnd can be saved as a congestion threshold.
 This is also known as the “slow start threshold” ssthresh.

19. 19
Figure 6.11 Behavior of TCP
Congestion Control
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
Time (seconds)
70
30
40
50
10

20. 20
Fast Retransmit
 Coarse timeouts remained a problem, and Fast retransmit
was added with TCP Tahoe.
 Since the receiver responds every time a packet arrives, this
implies the sender will see duplicate ACKs.
Basic Idea:: use duplicate ACKs to signal lost packet.
Fast Retransmit
Upon receipt of three duplicate ACKs, the TCP Sender
retransmits the lost packet.

21. 21
Fast Retransmit
Generally, fast retransmit eliminates about half
the coarse-grain timeouts.
This yields roughly a 20% improvement in
throughput.
Note – fast retransmit does not eliminate all
the timeouts due to small window sizes at the
source.

22. 22
Figure 6.12 Fast Retransmit
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 6
Retransmit
packet 3
ACK 1
ACK 2
ACK 2
ACK 2
ACK 6
ACK 2
Sender Receiv er
Fast Retransmit
Based on three
duplicate ACKs

23. 23
Figure 6.13 TCP Fast Retransmit Trace
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0
Time (seconds)
70
30
40
50
10

24. 24
Congestion
window
10
5
15
20
0
Round-trip times
Slow
start
Congestion
avoidance
Congestion occurs
Threshold
TCP Congestion Control

25. 25
Fast Recovery
Fast recovery was added with TCP Reno.
Basic idea:: When fast retransmit detects
three duplicate ACKs, start the recovery
process from congestion avoidance region
and use ACKs in the pipe to pace the
sending of packets.
Fast Recovery
After Fast Retransmit, half cwnd and commence
recovery from this point using linear additive increase
‘primed’ by left over ACKs in pipe.

26. 26 Modified Slow Start
With fast recovery, slow start only
occurs:
At cold start
After a coarse-grain timeout
This is the difference between
TCP Tahoe and TCP Reno!!

27. 27
Congestion
window
10
5
15
20
0
Round-trip times
Slow
start
Congestion
avoidance
Congestion occurs
Threshold
TCP Congestion Control
Fast recovery
would cause a
change here.

28. 28 Adaptive Retransmissions
RTT:: Round Trip Time between a pair of hosts on the Internet.
 How to set the TimeOut value?
 The timeout value is set as a function of the expected RTT.
 Consequences of a bad choice?

30. 30 Original Algorithm
 Keep a running average of RTT and compute TimeOut as a function of this RTT.
 Send packet and keep timestamp ts .
 When ACK arrives, record timestamp ta .
SampleRTT = ta - ts

31. 31 Original Algorithm
Compute a weighted average:
EstimatedRTT = α x EstimatedRTT + (1- α) x
SampleRTT
Original TCP spec: α in range (0.8,0.9)
TimeOut = 2 x EstimatedRTT

32. 32 Karn/Partidge Algorithm
An obvious flaw in the original algorithm:
Whenever there is a retransmission it is impossible to know whether to
associate the ACK with the original packet or the retransmitted packet.

33. 33
Figure 5.10
Associating the ACK?
Sender Receiv er
Original transmission
ACK
Retransmission
Sender Receiv er
Original transmission
ACK
Retransmission
(a) (b)

34. 34 Karn/Partidge Algorithm
1. Do not measure SampleRTT when sending packet more than once.
2. For each retransmission, set TimeOut to double the last TimeOut.
{ Note – this is a form of exponential backoff based on the believe that the lost
packet is due to congestion.}

35. 35 Jaconson/Karels Algorithm
The problem with the original algorithm is that it did not
take into account the variance of SampleRTT.
Difference = SampleRTT – EstimatedRTT
EstimatedRTT = EstimatedRTT +
(δ x Difference)
Deviation = δ (|Difference| - Deviation)
where δ is a fraction between 0 and 1.

36. 36 Jaconson/Karels Algorithm
TCP computes timeout using both the mean
and variance of RTT
TimeOut = µ x EstimatedRTT
+ Φ x Deviation
where based on experience µ = 1 and Φ = 4.

38. CSC 482/582:
Computer Security
TCP Defences
Random ISNs
If attacker can’t guess sequence numbers of a connection,
session can’t be hijacked
Adding a random number to previous ISN insufficient
Some “random” schemes can be statistically attacked
Cryptographically Secure Protocols
Connections reject packets that aren’t correctly encrypted as
part of the application stream
Still vulnerable to RST sniping

39. TCPHeader
RST (1 bit) – Reset the connection
FIN (1 bit) – No more data from sender

40. CSC 482/582:
Computer Security
TCP 3-way Handshake

42. RST/FIN Flood
 Attackers send highly-spoofed RST or FIN packets at an extremely high rate that do
not belong to any session within the firewall's state-table and/or server’s session
tables. The RST or FIN flood DDoS attack exhausts a victim’s firewalls and/or
servers by depleting its system resources used to look up and match these
incoming packets to an existing session.

43. FIN/RST Flood and Mitigation
Attacker
ServerFin/Rst
Fin/Rst
Fin/Rst
Fin/Rst
• Protection: Check session table if packets are real.

44. CSC 482/582:
Computer Security
TCP Session Killing
RST
Need one valid TCP sequence number
Send RST segment with spoofed IP address and
valid sequence number
May need to send multiple RST’s in case host
receives TCP segment with your chosen sequence
number before your RST segment
FIN
Need valid TCP sequence + ACK numbers
Send FIN+ACK segment with spoofed IP address
to terminate session
Receive FIN packet in response, verifying kill if
successful

45. CSC 482/582:
Computer Security
TCP FIN scan
Send TCP FIN packet and wait for response
No response
 Port is open
RST
 Port is closed.
Advantages: more stealthy than SYN scan
Disadvantages: MS Windows doesn’t follow standard
(RFC 793) and responds with RST in both cases,
requires root privilege.

46. Fin scan

47. CSC 482/582:
Computer Security
Defences
Prevention
 Disable unnecessary services.
 Block ports at firewall.
 Use a stateful firewall instead of packet filter.
Detection
 Network Intrusion Detection Systems.
 Port scans often have distinct signatures.
 IPS can react to scan by blocking IP address.