First of all, I must say that "Keep-Alive" storm is the name I call,
maybe it's a right name.
I learnt the IP spoofing attack several days ago, and tried to use FIN
to stop a TCP connection.
Of course, I let this attack happen in my own computer.
My OS is Linux, and I have a virtual machine, and OpenBSD runs in it.
The IP of Linux is 192.168.84.1, and OpenBSD's is 192.168.84.130.
The FTP Server runs on Linux, and the FTP Client runs on OpenBSD.
Then when the client connects the FTP Server, a IP spoofing attack
happens, and a FIN packet is sent, which pretends to send from the
client to the server.
Ethereal records the whole process, which is showed as following:
No. Time Source Destination
Protocol Info
3 3.345220 192.168.84.130 192.168.84.1 TCP
24369 > ftp [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460 WS=0
TSV=991816219 TSER=0
4 3.345262 192.168.84.1 192.168.84.130 TCP
ftp > 24369 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460
TSV=11116687 TSER=991816219 WS=3
5 3.345347 192.168.84.130 192.168.84.1 TCP
24369 > ftp [ACK] Seq=1 Ack=1 Win=16384 Len=0 TSV=991816219
TSER=11116687
6 3.347248 192.168.84.1 192.168.84.130 FTP
Response: 220 (vsFTPd 2.0.3)
7 3.516043 192.168.84.130 192.168.84.1 TCP
24369 > ftp [ACK] Seq=1 Ack=21 Win=16384 Len=0 TSV=991816219
TSER=11116687
8 21.041885 192.168.84.130 192.168.84.1 FTP
Request: USER anonymous
9 21.041917 192.168.84.1 192.168.84.130 TCP
ftp > 24369 [ACK] Seq=21 Ack=17 Win=5792 Len=0 TSV=11121111
TSER=991816254
10 21.042208 192.168.84.1 192.168.84.130 FTP
Response: 331 Please specify the password.
11 21.042718 192.168.84.130 192.168.84.1 TCP
24369 > ftp [FIN, ACK] Seq=17 Ack=21 Win=31744 Len=0
12 21.042768 192.168.84.1 192.168.84.130 FTP
Response: 500 OOPS:
13 21.042840 192.168.84.130 192.168.84.1 TCP
[TCP Keep-Alive] 24369 > ftp [ACK] Seq=17 Ack=55 Win=16384 Len=0
TSV=991816254 TSER=11121111
14 21.042908 192.168.84.1 192.168.84.130 TCP
[TCP Keep-Alive ACK] ftp > 24369 [ACK] Seq=65 Ack=18 Win=5792 Len=0
TSV=11121111 TSER=991816254
15 21.042986 192.168.84.130 192.168.84.1 TCP
[TCP Keep-Alive] 24369 > ftp [ACK] Seq=17 Ack=55 Win=16384 Len=0
TSV=991816254 TSER=11121111
16 21.043033 192.168.84.1 192.168.84.130 TCP
[TCP Keep-Alive ACK] ftp > 24369 [ACK] Seq=65 Ack=18 Win=5792 Len=0
TSV=11121111 TSER=991816254
17 21.043084 192.168.84.130 192.168.84.1 TCP
[TCP Keep-Alive] 24369 > ftp [ACK] Seq=17 Ack=55 Win=16384 Len=0
TSV=991816254 TSER=11121111
18 21.043129 192.168.84.1 192.168.84.130 TCP
[TCP Keep-Alive ACK] ftp > 24369 [ACK] Seq=65 Ack=18 Win=5792 Len=0
TSV=11121111 TSER=991816254
.....
1223 49.878986 192.168.84.130 192.168.84.1 FTP
[TCP Out-Of-Order] Request: PASS a
1224 49.879026 192.168.84.1 192.168.84.130 TCP
ftp > 24369 [RST] Seq=55 Ack=1914296628 Win=0 Len=0

I don't show most of keep-alive packets here because there are too
many.
The two OS spend most of CPU time sending these keep-alive packets.
As the matter of fact, the first Keep-Alive packet is not a real
Keep-Alive one. The faked FIN packet makes the FTP server believe that
the sequence of the client should be 18.
What confuses me is why this "keep-alive" storm happens, I mean, why
the server and the client send the "keep-alive" packets continually.
I tried to make another "keep-alive" storm again by faking another
packet such as a data packet which only carries one byte or the packet
just like the first keep-alive packet above, and whose SEQ is
SND.NXT-1.
Unfortunately, these packets don't cause the storm, and only make the
other side return a keep-alive ack packet.
So does anyone have some idea about how this "Keep-Alive" storm
happens?
If anyone knows, please let me know. This problem bothers me for a long
time.
Thank you.