#6 retransmitted ACK may initiate connection state transition

[Sasha Nedvedicky]

the way how IPF performs TCP state transition now is as follows.

check packet fits TCP window,

check whether packet (SYN,FIN,RST) moves connection to next state

if packet fits window clear timer associated with connection state

the current stateful inspection code assumes there are no packet
retransmissions, and we know retransmissions happen time to time.
let's look what can happen when packet is retransmitted:

Assume there is an established connection already.

client sends ACK

IPF sees ACK

ACK gets lost

server sends FIN
moves to FIN_WAIT_1
state

IPF sees server's FIN
moves server's
connection's state to
FIN_WAIT_1 state

client receives
FIN and retransimits
ACK, keeps
ESTABLISHED state

IPF deems retransmitted
ACK as an ACK for server's
FIN. client's connection
state is moved to
CLOSE_WAIT. [ 1 ]

server sees client's ACK
at last and sends ACK
for it.

IPF sees ACK and keeps
FIN_WAIT_1 state for
server

client recvs ACK

CLOSE_WAIT, FIN_WAIT_1
times out now at IPF

client has some
data to send

Since state entry has
timed out packet does
not match state

we see this might lead to falsely/unintentionally blocked packets, expiread
NAT table entries.

the way to fix it is to ensure the fr_tcp_age function will keep records of
sequence numbers for packets with control flags (FIN, SYN, RST).
then fr_tcp_age() at [ 1 ] must check ostate and ACK number do decide
whether it is time to move to another state or not.

[Darren]

[Darren]

Logged In: YES
user_id=1448875
Originator: NO

File Added: patch.diffs

[Darren]

Logged In: YES
user_id=1448875
Originator: NO

Due to issues trying to make this work for 4.1.*, it is being punted on for inclusion in 5.x.